I’ve got a multithreaded server; quite common to fire off a thread to deal with a database query or do some hard sums, so it doesn’t slow down the main thread. But a pain when that thread wants to Send() it’s result back to one or more clients.
Is this likely to be looked at in the future, or are we stuck with single threading for good?
We are working on server lib, but i’m sure there will not any implicit locking inside. The reason: different user design and implementation will require different locking strategy… Imagine I added implicit lock to the send, and receive following request: “Dear developer, I spent a lot of time working on performance my server code, after all I did it lock and wait free, so it is super fast now, hence I found that Send() function call mutex.lock inside which is quite slow operation, could you remove this code…” What we need to answer? 
So I think it is much better to leave locking strategy to developer. Isn’t it?
Yep, it’s good to leave the locking strategy to the developer, but I don’t see anything to lock, to enable me to use Send() from a separate thread. If there was something I could lock to use Send, I’d be happy with that.
hmmm, I don’t know is it good idea or bad:) It is probably because, actually, I don’t understand what is prevent you to create your lock for send()? Is it because you use HLAPI and LLAPI together?
If you can call Send() directly, you can add mutex to this call, correct?
Anyway, what I can promise that we will take into account your suggestion when we will make decision
Yes you don’t need something internal exposed for locking, as you can lock on anything you want. Create a method that all your threads can access, and place the send() call inside a lock, using an object of your choosing as the lock.
Then just direct all your send() calls to that method.
ty all What I’m using for now is a Queue which is processed regularly. All Sends() are put on the Queue from whatever thread, and the main server loop which does the Reading, now also handles the Send()ing