The Proton IOCP implementation provides a reactor capability over the proactor API, which mostly works as you expect.
I would remind folks of the following Windows-isms compared to POSIX: Windows was late to the tcp/ip party (championing LAN Manager) and 3rd parties provided tcp/ip stacks for a long time. A socket was an alien entity that was supposed to use different APIs from other file handle things. This persists to this day and is why you can't mix a Windows pipe and socket in a single Windows selection mechanism. Hence the documented restrictions on pn_pipe(). Well you can mix them in IOCP, because that came along after Microsoft was in the tcp/ip game. But that has other consequences: a socket doesn't have fluid usage in IOCP since it can be bound only once. Once "selected" within Proton, it cannot be used in another IOCP context elsewhere. Proton can support external loops provide its own loop allow applications to completely manage IO themselves (i.e. qpid cpp) Proton appears to be close to supporting a Dispatch-level of concurrency. Is the above enough, or do we have to find extensions to these that are useful to developers but don't stretch the differences between Windows and POSIX beyond possibility? On Thu, Feb 26, 2015 at 12:22 PM, Andrew Stitcher <astitc...@redhat.com> wrote: > On Thu, 2015-02-26 at 15:09 -0500, Rafael Schloming wrote: >> ... >> It sounds like one way or another we need at least some design changes. I >> don't think it's workable to have overlapping/close but distinct semantics >> for the API on different platforms (e.g. you can move sockets on one >> platform but not on another). I'm starting to think we either need one >> platform to precisely and fully emulate the semantics of the other >> platform, or they both need to implement some interface that is slightly >> higher level and can better accommodate the differences. > > I may have misremembered, but I think the essential platform difference > here is that Windows IOCP really tries to implement a Proactor type of > pattern rather than the reactor type of pattern that we are using in > Proton. > > [Proactor is where fundamentally the system calls back a processing > function on a thread that you give it] > > In the qpid implementation I had to effectively make the exposed > interface a proactor type interface in all platforms, to bridge the gap. > > I'm not sure this is workable in a context where the user can supply > their own event loop. > > Andrew > >
