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 <> 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

Reply via email to