On Tue, Nov 16, 2010 at 5:43 AM, Martin Lucina <[email protected]> wrote: > [email protected] 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
