[
https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047552#comment-15047552
]
Cliff Jansen commented on PROTON-1071:
--------------------------------------
I would suggest the following possibilities:
1. C API extension
- Assert no IO thread safety in Proton, i.e. weaker than dispatch (except
next line)
- new pn_io_iterrupt(pn_io_t *io, handler); <- may be called on any thread
- add interrupt event
- rework EventInjector to use interrupt event
2. Make Windows pn_pipe thread safe on write side (formalize self-pipe trick)
- Assert no IO thread safety in Proton, i.e. weaker than dispatch (with
single exception)
- pn_write on the write-side fd/handle of a pn_pipe may be called on any
thread
- rework EventInjector to use pn_pipe and pn_read/pn_write
- Assume multi-threaded Proton applications will use their own IO and
connection_engine
3. Strive for Posix level of thread safety
- Make same thread safety guarantee on Windows io.c and selector.c as Posix
via locking
- rework EventInjector to use pn_pipe and pn_read/pn_write
- Assume high performance applications will use their own IO and
connection_engine
- Fix API for pn_io_error and pn_io_wouldblock
While not related to the issue of event injection, it is worth noting that the
Windows IO could be broadened in each of the above scenarios to include
filesystem handles (easy) and stdin (medium easy, but requiring an extra
Proton-owned thread) and probably anything else (less easy). External unbound
sockets are already supported with the caveat that once selected, they are
forever bound to the Proton selector's completion port and cannot be used
within IOCP elsewhere (another Proton pn_io_t or external IOCP-based selector).
> 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)
