[zeromq-dev] patch: non-blocking tcp accept
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 */
#else /* _XOPEN_SOURCE_EXTENDED */
#define EWOULDBLOCK 54
#endif /* _XOPEN_SOURCE_EXTENDED */
Might help de-confuse?
More information about the zeromq-dev