[zeromq-dev] implementing zmq_unbind() and/or zmq_disconnect() discussion
Pieter Hintjens
ph at imatix.com
Mon Apr 16 13:33:54 CEST 2012
Hi Sergey,
> Wow this is sick sick sick...
Sorry, but this made me laugh. :)
unbind/disconnect would be _extremely_ useful and you're not the first
person to look at this.
Trying to make a perfect solution isn't going to help IMO. There are
system limits on how many endpoints you can bind to anyhow, and in
practice they will be small numbers, on any given node. And
unbind/disconnect are not on the critical message processing path,
I'd aim to do this by brute-force, without worrying about elegance or
performance, then let people try it, and see how it works, and then
improve it over time.
-Pieter
On Sun, Apr 15, 2012 at 10:17 AM, Sergey Hripchenko
<shripchenko at intermedia.net> wrote:
> I was thinking about those, but ran into infinite troubles/questions.
> Could someone please review my thoughts and maybe advise me on it, since I'm
> not sure that i correctly and fully understand the whole code-base.
>
> The most zmq-ish and framework-ish ^) way is to create a new method
> 'own_t::broadcast_to_all_owned()' and send a command from 'session_base_t'
> to all children to compare
> command's argument of type 'address_t *p' with their '*_listener_t::addr' /
> 'session_base_t::addr' and if it matches then child will call its
> 'own_t::terminate()' method.
> However there are various de/allocation issues with passing endpoint address
> in the command.
> I cannot pass a class in command_t::args since it is union.
> I cannot pass 'char*' because all commands are async and i cant reliably
> free() it in the parent level and cant free() it on a children's level since
> it would be multiple-free().
> I'm not sure that i could reliably use ref-counting-pointer since it is too
> fragile and i suspect that commands could be skipped/lost on a children's
> level in case of child shutdown.
> And how this 'send command to all children stuff' will scale in case of 1
> 000 000 endpoints....
>
> Or we could break 'own_t' class logic and expose
>
> // List of all objects owned by this socket. We are responsible
> // for deallocating them before we quit.
> typedef std::set <own_t*> owned_t;
> owned_t owned;
>
> as a 'protected' member for read-write operations?
> and then just
> foreach(owned) {
> if((session *l = dynamic_cast<session *>(owned[i]))!=NULL) {
> if( match l.addr) then send_term (l);
>
> given that every 'session *l' live in different threads. hoping they don't
> modify their endpoint address string and assuming that if the object is in
> 'owned' array it alive and not in terminating phase
> (according to 'own_t' code). Wow this is sick sick sick...
>
>
> I'm sure there should be another way...
>
> ________________________________
>
> This message is intended only for the person(s) to which it is addressed and
> may contain Intermedia.net Inc privileged, confidential and/or proprietary
> information. If you have received this communication in error, please notify
> us immediately by replying to the message and deleting it from your
> computer. Any disclosure, copying, distribution, or the taking of any action
> concerning the contents of this message and any attachment(s) by anyone
> other than the named recipient(s) is strictly prohibited.
>
> _______________________________________________
> 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