[
https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046607#comment-15046607
]
Cliff Jansen commented on PROTON-1071:
--------------------------------------
There is no concept in Windows of a general select/poll that works on generic
file descriptors/handles. You have a separate synchronous wait model for each
file type. On top of that, you have a fancy proactor model (IO completion
ports, IOCP) for asynchronous IO on a few file types: sockets and named pipes,
but not console IO and anonymous pipes. The IOCP model is the preferred
scalable IO mechanism for one or many threads.
If using pn_selectable_set_fd(handle_xx) with IOCP, it cannot work for any
handle_xx that is not IOCP aware. Well not without adding an extra thread that
synchronously checks it (something that may have to be done for console IO).
PROTON-688 was an attempt to find a useful subset of Posix and Windows
capabilities (and other platforms, if identified) for performant IO (mostly
looking at the dispatch router model). Threading consequences were one
consideration, but so was mere achievability. The network (socket) IO plus
pipe (interrupt mainly) IO were the prime candidates.
Hence an "fd" in pn_selectable_set_fd is actually a pn_socket_t, not an int.
An external socket may be used in this case, but also a pn_pipe object. In
Posix, the pn_pipe is not an OS socket. In Windows, it currently is but may
become something else, perhaps even an internal construct in future.
Another difference to note, a Posix fd can move between different collections
fds for poll/select. A Windows handle can be registered exactly once with a
collection. It can never be moved to another selector. It is associated with
a single IOCP port until it is closed.
> EventInjector hangs on Windows
> ------------------------------
>
> Key: PROTON-1071
> URL: https://issues.apache.org/jira/browse/PROTON-1071
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
> Affects Versions: 0.11
> Environment: Windows
> Reporter: Ken Giusti
> Assignee: Cliff Jansen
> Fix For: 0.12.0
>
>
> I added a new reactor test that exercises the python-proton ApplicationEvent
> and EventInjector classes:
> proton_tests.reactor.ApplicationEventTest.test_application_events
> See tests/python/proton_tests/reactor.py
> This test passes on linux, but hangs when run on Windows.
> Poking around a bit, I suspect the problem may be in the Windows selector
> code. Description:
> The EventInjector/ApplicationEvent classes provide a way to trigger events
> from threads external to the reactor main loop. See
> proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the
> reactor when a new event is sent to the reactor (see reactor.py in the python
> bindings). The EventInjector's trigger method puts the event on a queue and
> writes to a pipe to wake up the reactor. The on_selectable_readable callback
> in the EventInjector is called on the reactor thread to get the event off the
> queue and clear the pipe.
> On windows it appears as if the EventInjector selectable is made "readable"
> even though nothing has been written to the pipe. This causes the os.read()
> call in the on_selectable_readable() callback to hang.
> Best I can tell the windows selector code doesn't work properly with a pipe.
> The pn_selector_next() function is returning a read event on the pipe's read
> descriptor even though the pipe is empty. But I'm not familiar with the
> window's selector implementation, so this is a best guess.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
