Hi,
I am trying to create code for level-triggered socket polling, but I ran into a rather bizarre WSA-specific understanding of what level-triggered means and how it should work, namely re-enabling functions.
See, true level-triggered polling works by triggering requested events every time if conditions for that event are met. For example, if a socket has data to read, read event must be triggered every time whether or not there was a call to "re-enabling"recv() function in between. Similarly, if a listening socket has pending connections, accept event must be triggered every time whether or not there was a call toaccept() function. This should work for writing to a socket as well, as in, if a socket is able to successfully processsend() function, write event should be triggered every time.
Now, I've made a workaround to inconsequentially re-enable FD_READ, FD_OOB, and FD_WRITE events by calling their respective re-enabling (namely,recv() and send()) functions with a buffer size of 0 (zero) bytes, effectively reading and/or writing nothing from/to the socket, but still re-enabling their respective events. All fine and dandy, but then came my nemesis, FD_ACCEPT.
Documentation for WSAEventSelect() function states that "any call to the reenabling routine, even one that fails, results in reenabling of recording and signaling for the relevant network event and event object." Great, except for the fact that this is not true. I have provided accept()(a FD_ACCEPT event re-enabling function) with an addr buffer the size of 0 (zero) bytes with the explicit intent for it to fail, and it predictably did fail with an error codeWSAEFAULT, but this failed call to accept() did not re-enable FD_ACCEPT event, even though it should have.
I know I've already written half of a novel here, so my question will be short and simple: Is there a way to re-enable FD_ACCEPT event without a successful call toaccept() function?
Thanks.