> 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? > > Andrew Stitcher wrote: > 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's understanding matches my recollection as well - if you make a SOCKET handle available, the user can get a signalable HANDLE from that. Just clearly document that it's a Windows SOCKET handle and the user can take it from there. I haven't followed all the code through to check what else may be needed, but, using a WSAEventSelect() handle, the handle will be signaled upon socket readability, then won't be signaled again until the socket is read, then more data becomes available - WSAEventSelect is edge triggered, whereas select() is level triggered. I think this will be ok but you should check this scenario in the code. There's no nice socketpair() on Windows - you'll need to create a loopback socket yourself. Resource-wise, yes, it's more expensive than a single event, but I don't see much choice. The bigger pain is for the user who elects to use an event handle instead of the socket - he now has to manage a handle that's tied to a SOCKET he doesn't control. But, again, without more user input as to how this will be used I don't see much choice. I think it would be good to keep the qpid-modeled directory scheme with OS-specific directories holding OS-specific code. - Steve ----------------------------------------------------------- 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 > >
