Review Board 1.7.22


Provides the EventNotifier type, plus example agent and unit test.

Review Request #1557 - Created Aug. 17, 2011 and submitted

Darryl Pierce
Reviewers
qpid
kgiusti, mick, tross
qpid
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.
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.
Review request changed
Updated (Sept. 2, 2011, 9 p.m.)
Updated with the initial Windows implementation.
Posted (Sept. 2, 2011, 9:18 p.m.)
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)
  1. 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?
  2. 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.
  3. 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.