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