Hi Cliff, I agree that the current extra API call is kludgy if not downright ugly.
I noticed today you already added a new API call pn_io_selector(), which has separate windows and posix implementations. For short term 'fix', I'd propose to hide my hack inthere -- make calling pn_io_selector() turn on the iocp on windows. Bozzo This would not impact the API and would restore the On 9. 09. 14 07:02, Cliff Jansen wrote: > Ho Bozo, > > Thank you for comments and the suggested patch. I would prefer a > solution that did not have a special Windows-only-sometimes call > "pn_io_no_iocp()". It seems to me anyway that there is another class > of sockets that are pulled into an IOCP context too early, so that a > separate solution is required that should fix your problem too. > Basically, a more lazy enlistment strategy should leave you outside > IOCP and fix the other issue too. > > Based on your problem and how Dispatch strives for multithreaded > performance, I think I have a better handle on what Proton should be > providing for small to medium-large scalability. > > I am going to try to define what is a sensible intersection of Windows > and Posix capabilities to be supported by the proton > io/selector/selectable classes in a separate documentation JIRA and > try to get a fix for you ASAP, probably in yet another JIRA. > > Cliff
