[zeromq-dev] Fwd: ZMQ Closure - Change of Beginners Documentation

[Mike Pearce]

Hi Pieter,

I completely disagree. The section is inaccurate and there is no more detail
to be found in later chapters. It states that an error in 0MQ exists that
requires that all sockets must be closed in advance of calling zmq_term.
This is incorrect for two reasons -
1. I do not believe that there is an error in ZMQ
2. zmq_term is designed to unblock socket commands in order for the socket
closure. To follow the beginners guide you must issue the zmq_close commands
from outside of the blocked call and the only way to do this is to ignore
the threading limitation of the commands.

A beginner to 0MQ is unlikely to be a beginner to computing and
multithreaded application programming is common place. You cannot write a
GUI without going multithreaded and so I doubt there are many single
threaded programs left. You also cannot avoid polling reads until you
consider a separate read thread making a blocking call.

I do agree that the guide should remain simple but I prefer that it gets
reworded. It is a great guide but this section has become inaccurate over
time.

I would like that this section of the guide have the following added -
1. It states that the socket functions are not thread safe and so anyone
implementing a multithreaded application solution must adhere to this.
2. It states that if the users application is doing a blocking read then
zmq_term is the means by which this blocked read will get unblocked. By
implication an application that implements a blocked read will need to be
multithreaded.

If this advice is not added then you will have missed a great opportunity to
warn new users about this potential pitfall and anyone that implements a
solution based upon the current advice will see a ZMQ that is unstable and
it will appear to them that the product is not good. This is a shame because
the product is good.

Please remember that this one little section in the beginners guide is the
only information offered regard 0MQ termination by this guide and there is
no alternative users guide offered from this part of your website.

Mike





On Thu, May 26, 2011 at 3:15 AM, Pieter Hintjens <ph at imatix.com> wrote:

> On Wed, May 25, 2011 at 8:22 AM, Mike Pearce <mike at kaew.be> wrote:
>
> > I can assure everyone that what I wrote is a lot better than the very
> > inaccurate section that currently exists and I am a bit sad that my
> > submission ended so abruptly.
>
> Well... the section you pointed to is in Ch1 and intended for people
> starting to use 0MQ. We don't discuss multithreaded apps anywhere in
> that section and it'd be inappropriate to start suddenly talking about
> that before people have even understood what 0MQ really is.
>
> There is lots of discussion about multiple threads later, including
> quite explicit (in bold) instructions about how to handle ETERM and
> how not to share sockets between threads:
>
> http://zguide.zeromq.org/page:all#toc30
> http://zguide.zeromq.org/page:all#toc38
>
> I'm happy to add a note earlier on saying, 'warning, if you're doing
> multiple threads', it's more complex than this', but for beginners the
> advice is exactly as I wrote it. Close your sockets, THEN do zmq_term.
> If you don't your app will block.
>
> This is only misleading if you don't read the rest of the text.  But
> since good design takes into account how people actually work, not how
> we hope they'd work, I'll fix the text.
>
> -Pieter
> _______________________________________________
> 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/20110526/44cc670f/attachment.htm>