> On 2011-09-02 21:18:55, Steve Huston wrote: > > In the test program, isReadable won't sense a signaled Windows event > > handle. If the usage model for this feature is a select-able handle you > > will need a socket. What is the intended model? > > > > In the Windows code, the convention is to prefix system calls with :: > > (e.g., ::CreateEvent) > > > > Other areas of qpid that have OS-specific code keep it in a OS-specific > > directory (qpid/sys/windows) > > Darryl Pierce wrote: > I used the HANDLE model rather than a socket due to previous discussions > where that was the idea kicked around. Are there any resource hits on using a > socket pair rather than a HANDLE for this mechanism? If not, I'll move it > over. > > Thanks for the note on :: before WinAPI calls. I've added them. > > Under QMF there are no OS-specific directory packages. Are we interested > in creating such a packaging under QMF?
My understanding of the previous discussion is that both HANDLE and something selectable need to be provided as it is impossible to know what a given application program might need. The additional piece of information was that you can create a HANDLE from a socket using WSAEventSelect() which will signal if the socket is either readable or writeable depending on what you choose. - Andrew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1557/#review1739 ----------------------------------------------------------- On 2011-09-02 21:00:31, Darryl Pierce wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/1557/ > ----------------------------------------------------------- > > (Updated 2011-09-02 21:00:31) > > > Review request for qpid, Kenneth Giusti, michael goulish, and Ted Ross. > > > Summary > ------- > > Provides a new method for providing notification to an interested party when > new messages are received. > > The EventNotifier class can be associated with either a console or agent > session. The object provides a file descriptor which then becomes readable > when there are messages to be processed. > > This implementation only supports Posix. There is some work necessary to get > a Windows implementation in place. > > > Diffs > ----- > > trunk/qpid/cpp/bindings/qmf2/examples/cpp/Makefile.am 1164327 > trunk/qpid/cpp/bindings/qmf2/examples/cpp/event_driven_list_agents.cpp > PRE-CREATION > trunk/qpid/cpp/include/qmf/AgentSession.h 1164327 > trunk/qpid/cpp/include/qmf/ConsoleSession.h 1164327 > trunk/qpid/cpp/include/qmf/PosixEventNotifier.h PRE-CREATION > trunk/qpid/cpp/include/qmf/WindowsEventNotifer.h PRE-CREATION > trunk/qpid/cpp/src/CMakeLists.txt 1164327 > trunk/qpid/cpp/src/qmf.mk 1164327 > trunk/qpid/cpp/src/qmf/AgentSession.cpp 1164327 > trunk/qpid/cpp/src/qmf/AgentSessionImpl.h PRE-CREATION > trunk/qpid/cpp/src/qmf/BaseEventNotifierImpl.h PRE-CREATION > trunk/qpid/cpp/src/qmf/BaseEventNotifierImpl.cpp PRE-CREATION > trunk/qpid/cpp/src/qmf/ConsoleSession.cpp 1164327 > trunk/qpid/cpp/src/qmf/ConsoleSessionImpl.h 1164327 > trunk/qpid/cpp/src/qmf/PosixEventNotifier.cpp PRE-CREATION > trunk/qpid/cpp/src/qmf/PosixEventNotifierImpl.h PRE-CREATION > trunk/qpid/cpp/src/qmf/PosixEventNotifierImpl.cpp PRE-CREATION > trunk/qpid/cpp/src/qmf/WindowsEventNotifier.cpp PRE-CREATION > trunk/qpid/cpp/src/qmf/WindowsEventNotifierImpl.h PRE-CREATION > trunk/qpid/cpp/src/qmf/WindowsEventNotifierImpl.cpp PRE-CREATION > trunk/qpid/cpp/src/tests/EventNotifierTest.cpp PRE-CREATION > trunk/qpid/cpp/src/tests/Makefile.am 1164327 > > Diff: https://reviews.apache.org/r/1557/diff > > > Testing > ------- > > An example agent takes the existing list_agents and uses an EventNotifier to > respond to incoming messages rather than blocking on the > ConsoleSession.nextReceiver() API. > > A unit test verifies that the file handle provides by the EventNotifier type > is properly updating on incoming messgaes. > > > Thanks, > > Darryl > >
