wxSocketEvent not being sent while modal dialog is open

1    26 Oct 2016 07:50 by u/tame

Alright so I take back all the nice things I said about wxWidgets. I'm using wxSocketClient to connect to a server and do some stuff. I call wxSocket::SetEventHandler() to register for events, and (after finding this bug report and making the change suggested there... pretty sad that such an easily reproducible bug has been so well documented for nearly two years and it's still marked as 'new') it's been working alright... except if I pop up a modal dialog box, at which point I stop getting input events when data's received. If I close the dialog quickly before the connection times out, the events do get delivered.

Anyone have any idea what's going on, before I throw wxSocket in the bin and just do it myself using winsock?

Edit for more details: Platform is Windows 8.1 using TDM-GCC, the whole application is single threaded and pretty simple. Tried clearing wxWS_EX_BLOCK_EVENTS from the dialog's window style, no dice.

4 comments

1 u/lemon11 26 Oct 2016 08:08

Modal dialogs choke off the main event loop. The interface should be in its own process or thread, away from networking, ideally. Fork off for the socket or simply avoid anything like modal dialogs that pause the loop.

1 u/tame [OP] 26 Oct 2016 08:20

Yeah, they do their own little event loop inside ShowModal() but that should still pump the main event queue, right? My main window still gets other messages (timer ticks, etc.) Or does wxTimer not use the same event queue?

0 u/lemon11 26 Oct 2016 11:09

Strange. It's possible timers work on signals or something, yes. But I don't know Wx deeply enough, sorry.

1 u/tame [OP] 26 Oct 2016 11:20

Thanks for having a crack at it, at least! :)

I think I'm on the right track now. It turns out that WSAAsyncSelect() (which wxSocket uses internally to get callbacks) will only send one message after each call to recv(), but sometimes this message will be sent while the data is still being recieved, before select() / recv() can see it. So if you only ever call recv() from the event handler, AND it's guarded by a call to select() to see if there's any data waiting, then you can get very rare situation where a message is generated, select() says there's no data waiting, and so recv() is never called, which means no new events are generated. This seems to be what's going on inside wxMSW.

What this has to do with modal dialogs, I have NFI, except I guess they introduce some time lag that uncovered a race condition or something.

Edit: Nope, while I still think that's one problem, it looks like you were right about the message loop. Windows events still get handled but wxWidgets' internal events don't seem to get pumped while the dialog's message loop is running. Blah.