[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