[zeromq-dev] Portability of 0MQ API

Brian Granger ellisonbg at gmail.com
Mon Aug 9 21:22:52 CEST 2010


Hi,

Martin gives a good summary of what prompted the creation of zmq_errno.  In
the Python universe it is actually not uncommon to run into the CRT issues.
 We use zmq_errno exclusively in the Python bindings because of this issue.

Cheers,

Brian

On Mon, Aug 9, 2010 at 12:51 AM, Martin Lucina <mato at kotelna.sk> wrote:

> ph at imatix.com said:
> > Anyone have other ideas?  Two options that seem obvious but presumably
> > won't work are:
> >
> > * promote zmq_errno(3) for use on all platforms
> > * write the win32 error code to errno (mapping to Unix error codes too)
>
> I presume what you meant by the 2nd point is "Write the win32 error code to
> use errno". This is in fact the current state of affairs and provided
> certain factors are met code using errno will work just fine on Win32.
>
> Now to elaborate on those "certain factors": The reason zmq_errno(3) exists
> at all is that on Win32 you have this wonderful mess of different C runtime
> libraries, and the combination of (an application plus it's dependent DLLs)
> can put you in a situation where multiple C runtime libraries are in use.
>
> If you are in this unhappy situation, then you have a problem as the
> "errno" value does not get shared *between* those multiple C runtime
> libraries. Hence the the need for some mechanism for component Foo to ask
> whichever Bar version of the 0MQ library it might be using for "its" value
> of "errno", which is exactly what zmq_errno(3) does:
>
>    [from zmq.cpp]
>    int zmq_errno ()
>    {
>        return errno;
>    }
>
> The main use case for this on Win32 (and indeed the reason we came up with
> zmq_errno()) is language bindings, where the language runtime (e.g. Python)
> may be using (built with) a different CRT to that which LIBZMQ.DLL is using
> (built with).
>
> Note that this situation will never occur on a UNIX-like system since AFAIK
> there are no modern UNIX-like systems which allow you to mix CRTs. I'm sure
> you *could* get yourself into a situation like this if you really wanted to
> by doing various perverse things with dlopen() but then you're just
> shooting yourself in the foot.
>
> So, to summarize, I don't think we are asking users to write non-portable
> code. Users should be using just "errno", which will work fine on Win32,
> unless they're mixing CRTs in which case they should know about that and
> use zmq_errno(). I don't consider mixing CRTs to be a sane enough case that
> it would warrant telling everyone to use zmq_errno().
>
> The only action item I see from this is that maybe the scary comments in
> zmq_errno(3) should say something about mixing CRTs on Win32.
>
> Does this make sense?
>
> > We already use zmq_strerror(3) instead of strerror.
>
> This is necessary since 0MQ introduces it's own EXXXX errno codes which are
> not in POSIX. Obviously, strerror() does not understand these so you need
> to use zmq_strerror() instead. Same logic as for zmq_socket() vs socket().
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100809/144ef369/attachment.htm>


More information about the zeromq-dev mailing list