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

Pieter Hintjens ph at imatix.com
Mon Oct 11 22:14:33 CEST 2010


I like I but would use a more forceful term, like ZMQ_CAPTURE or
ZMQ_POSSESS. Nice idea, makes migration explicit...
On 11 Oct 2010 21:14, "Matt Weinstein" <matt_weinstein at yahoo.com> wrote:
> 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
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101011/c4217af1/attachment.htm>


More information about the zeromq-dev mailing list