[zeromq-dev] [PATCH] Scalability improvements for large amounts of connections

Matt Weinstein matt_weinstein at yahoo.com
Mon Oct 11 21:14:09 CEST 2010


Would implementing something like :

zmq_setsockopt(...ZMQ_MIGRATE...) // makes this socket MINE

be more useful?

The memory barrier would be called inside the setsockopt() call,  
reducing the black magic required of the user.

As a bonus you could store the owner's thread id in the socket, and  
return an error if the wrong thread tries to use the socket  
thereafter ... (EHANDSOFF ? :-) )

RSVP,

Best,

Matt

On Oct 11, 2010, at 2:39 PM, Pieter Hintjens wrote:

> On Mon, Oct 11, 2010 at 7:32 PM, gonzalo diethelm <gdiethelm at dcv.cl>  
> wrote:
>
>> It might also be a good idea to mention a couple of examples of a  
>> memory
>> barrier call from C / C++.
>
> Hmm, that will encourage people to play around with non-portable
> unsafe techniques.  Before today I didn't know how to do a memory
> barrier call, and tomorrow I hope I've forgotten again.  Anyhow,
> Wikipedia explains it.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list