[zeromq-dev] Java API is not notifed of C++ assert failures.

Martin Sustrik sustrik at fastmq.com
Wed Apr 15 20:29:23 CEST 2009


Pieter Hintjens wrote:
> On Wed, Apr 15, 2009 at 5:56 PM, Martin Sustrik <sustrik at fastmq.com> wrote:
> 
>> Second, 0MQ uses 'select' function to poll on the sockets. By default
>> select handles at most 64 sockets on Win32. The limit can be increased
>> by defining FD_SETSIZE macro to desired value before including winsocks
>> (select_thread.hpp/cpp). Maybe we should increase it to some reasonable
>> value ourselves (256?)
> 
> FD_SETSIZE is not the maximum number of open sockets, it's the highest
> socket handle number.  Win32 allocates socket numbers with holes, so
> the default value of 64 will give you maybe 16 sockets (a guess, not
> tested).  Try printing the actual socket numbers.

Actually, Win32 fd_set is not POSIX compliant. It's an array of file 
descriptors rather than a bit array. So if FD_SETSIZE is 64 you should 
be able to poll on exactly 64 sockets.

> Increasing FD_SETSIZE to something reasonable (1024 or higher) is
> pretty much mandatory for any win32 server.  The APR package we use in
> OpenAMQ sets it to 1024.  I've heard of people raising it to 16K on
> win32 without trouble.

Right, you can increase the limit as much as you wish. However, you have 
to keep in mind that large FD_SETSIZE means more copying and thus lower 
performance (both latency and throughput). FD_SETSIZE of 1024 means 4096 
bytes per fd_set structure - given that for each call to select you have 
to copy 3 fd_sets, you have to copy 12288 bytes just to enter polling.

Maybe keeping the default of 64 and allowing compile-time redefinition 
of the limit would be the best for now.

Moving to IOCP is the only viable long-term solution though.

Martin





More information about the zeromq-dev mailing list