[zeromq-dev] Mac OS X: test_shutdown_stress sometimes fails

[Dhammika Pathirana]

On Tue, Nov 16, 2010 at 5:43 AM, Martin Lucina <mato at kotelna.sk> wrote:
> sustrik at 250bpm.com said:
>> On 11/12/2010 11:34 AM, Christian Gudrian wrote:
>> > Hello, again!
>> >
>> > test_shutdown_stress proves stressing under Windows, too:
>> >
>> > The send call at mailbox.cpp:76 might return SOCKET_ERROR with
>> > GetLastError() == WSAEWOULDBLOCK. The wsa_assert macro ignores this
>> > special case and allows program execution as if nothing had happened.
>> > Eventually it's the following zmq_assert which aborts the program.
>> >
>> > Is there any reasonable way to appropriately handle this condition?
>> >
>> The buffer resizing code, such as the one in POSIX implementation of
>> mailbox_t::send should exist on windows as well.
>
> As Martin says, there is no reasonable way to handle WSAEWOULDBLOCK in
> mailbox_t::send(). If it's not failing on that right now then that's a bug
> and it should just assert.
>
> As for the buffer-resizing code for Windows, feel free to port the code
> from the POSIX implementation. I have no idea if on-the-fly resizing of a
> socket's SNDBUF will work reliably on Winsock.
>
> Even then the whole buffer-resizing operation is more a hack than anything
> else; unfortunately all the other options we investigated with Martin
> Sustrik for reimplementing the way mailbox_t works seem to be dead ends
> right now :-(
>


-1 for auto buffer resizing.
This is bound to go gaga anytime, and possibly has a remote trigger.

Different option is to send cmd_t struct pointers. It'll give about
16K commands with 128K
socket buffer. But this will require malloc'ing cmd_t structs, or we
can use a ring.

But isn't it fair to drop/backlog new connections if the application
can't keep up?


Dhammika