>
>
> 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.

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...
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to