[zeromq-dev] Thread Safe sockets

[Martin Sustrik]

On 06/02/12 22:38, Nadav Samet wrote:
>
>     What makes the problem bad is the fact that there may be arbitrary
>     interval between sending/receiving 1st and 2nd part of the message.
>     During that time the socket has to be locked which in turn means
>     that all other threads accessing it will be blocked for the period
>     (1 hour, for example).
>
>
> This is why I think the locking should be only implemented at
> the application/binding level. Only the application knows if everything
> that needs to be sent is available and it makes sense to lock the socket
> around a tight loop that sends a whole message.

Yes, makes sense.

> If we don't want to change the API, then another possibility would be to
> queue frames in thread local storage and once the last frame of a
> message arrives, lock the socket and send everything. But this involves
> thread local storage...

Unfortunately, TLS won't work. There are environments where sockets are 
being migrated from one thread to another (imagine Java VM moving the 
socket to gc thread). In such case, there'll remain stray TLS in the 
original thread.

Martin