[zeromq-dev] patch: non-blocking tcp accept

George Neill georgen at neillnet.com
Tue Apr 28 12:43:58 CEST 2009

On Tue, Apr 28, 2009 at 5:35 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Hi Dhammika,
>> Patch to add non-blocking tcp accept.
>> 1. sets non-blocking flag in tcp listener socket
>> 2. moves accept to tcp_listener.in_event()
>> 3. passes native socket descriptor to tcp_socket constructor
>> Builds and tested on linux.
>> Would appreciate if someone can run a quick build on a win32 box.
>> Hopefully it'll build without any drama.
>> Requires few changes in zmq_server, perf and examples (mainly in
>> tcp_socket constructor).
>> If we're happy with this, I'll send a full patch.
> The patch looks OK. Please, do send the full patch (and state it's
> licensed under MIT license).
> The one thing I'm unsure of is EAGAIN/EWOULDBLOCK distinction. It seems
> that both Linux and Win32 assign the same numeric value to both errors.
> I am not sure of other platforms.
> POSIX says:
>     Resource unavailable, try again (may be the same value as
>     Operation would block (may be the same value as [EAGAIN]).
> Pretty confusing...

from /usr/include/errno.h on AIX 5.3 ...

/* non-blocking and interrupt i/o */
 * AIX returns EAGAIN where 4.3BSD used EWOULDBLOCK;
 * but, the standards insist on unique errno values for each errno.
 * A unique value is reserved for users that want to code case
 * statements for systems that return either EAGAIN or EWOULDBLOCK.
#define EWOULDBLOCK     EAGAIN   /* Operation would block       */
#define EWOULDBLOCK     54

Might help de-confuse?


More information about the zeromq-dev mailing list