Hi Bozzo, Please take a look at PROTON-668 and confirm none of the assumptions are counter to your usage, especially whether you fit scenario 3 and do not have problems with the proposed restriction to pn_pipe. If this is OK for you, I think I am close to a fix that will work for you.
Cliff On Wed, Sep 10, 2014 at 4:51 AM, Bozo Dragojevic <[email protected]> wrote: > 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 >
