[zeromq-dev] Thread Safe sockets

[Chuck Remes]

On Feb 6, 2012, at 6:39 PM, john skaller wrote:

> There is one thing that might be interesting. Hmm.. There is a lock now *inside*
> the socket object where is needs to be.
> 
> So you could use non-safe sockets and the API:
> 
> 	lock(socket)
> 	unlock(socket)
> 
> This would work for multi-part messages. The functions would have to be called by the
> user, and only on un-safe sockets. In fact, an alternative is to provide these functions
> and get rid of the automatic locking based on the context of a flag in the socket.
> 
> ALTERNATIVE TS proposal:
> 
> 	void *lock(void *socket_t) // returns locked socket, arg must not be locked
> 	void *unlock(void *socket_t) // returns unlocked socket, arg must be locked
> 
> This puts locking back in the hands of the user BUT it keeps the mutex inside
> the object so the user doesn't have to worry about keeping the socket/mutex
> pairs associated.

While watching this thread, I can't help but think that you wish 0mq was a *much different* library than it is. I'm hoping that sustrik stays engaged with it at some level to indicate how much is feasible for his long-term vision (getting 0mq into the kernel) and how much of it is superfluous to that vision.

I think it will be quite difficult to accommodate your proposed changes while providing any kind of backward compatibility. But, I look forward to the continued discussion.

cr