|
|
A WinDispatcher provides an entity where callbacks for pending I/O operations on Windows sockets and other Windows system objects may be registered. The callbacks are invoked when the wait_and_dispatch method is called, and I/O is pending on a descriptor, or a Windows object's state has been set to signalled.
The entire event loop is driven from the Win32 API call WaitForMultipleObjects(), which means there is a hard 64-object limit.
This class is the glue which binds XORP to Windows. There are tricks in the AsyncFileOperator classes which are tightly coupled with what happens here. Most of these tricks exist because systems-level asynchronous I/O facilities cannot easily be integrated into XORP's current design.
There is no way of telling specific I/O events apart on objects other than sockets without actually trying to service the I/O. The class uses WSAEventSelect() internally to map socket handles to event handles, and much of the complexity in this class is there to deal with this schism in Windows low-level I/O.
The class emulates the ability of UNIX-like systems to interrupt a process waiting in select() for pending I/O on pipes, by using a time-slice quantum to periodically poll the pipes. This quantum is currently hard-coded to 250ms.
Sockets are optimized to be the faster dispatch path, as this is where the bulk of XORP I/O processing happens.
WinDispatcher should only be exposed to EventLoop.
WinDispatcher (ClockBase *clock)
| WinDispatcher |
~WinDispatcher ()
| ~WinDispatcher |
[virtual]
bool add_ioevent_cb (XorpFd fd,
IoEventType type,
const IoEventCb& cb,
int priority = XorpTask::PRIORITY_DEFAULT)
| add_ioevent_cb |
Add a hook for pending I/O operations on a callback.
Only one callback may be registered for each possible IoEventType, with the following exceptions.
If the XorpFd maps to a Windows socket handle, multiple callbacks may be registered for different IoEventTypes, but one and only one callback may be registered for the handle if a callback is registered for the IOT_ACCEPT event.
If the XorpFd maps to a Windows pipe or console handle, callbacks may only be registered for the IOT_READ and IOT_DISCONNECT events.
If the XorpFd corresponds to any other kind of Windows object handle, only a single callback may be registered, and the IoEventType must be IOT_EXCEPTION. This mechanism is typically used to direct the class to wait on Windows event or process handles.
Parameters:
fd | a Windows object handle encapsulated in a XorpFd . |
type | the IoEventType which should trigger the callback. |
cb | callback object which shall be invoked when the event is triggered. |
priority | the XorpTask priority at which this callback should be run. |
Returns: true if function succeeds, false otherwise.
bool remove_ioevent_cb (XorpFd fd, IoEventType type)
| remove_ioevent_cb |
Remove hooks for pending I/O operations.
Parameters:
fd | the file descriptor. |
type | the IoEventType to remove the callback for; the special value IOT_ANY may be specified to remove all such callbacks. |
Returns: true if function succeeds, false otherwise.
bool ready ()
| ready |
Find out if any of the selectors are ready.
Returns: true if any selector is ready.
int get_ready_priority ()
| get_ready_priority |
Find out the highest priority from the ready file descriptors.
Returns: the priority of the highest priority ready file descriptor.
inline void wait_and_dispatch (TimeVal* timeout)
| wait_and_dispatch |
Wait for a pending I/O events and invoke callbacks when they become ready.
Parameters:
timeout | the maximum period to wait for. |
void wait_and_dispatch (int ms)
| wait_and_dispatch |
Wait for a pending I/O events and invoke callbacks when they become ready.
Parameters:
millisecs | the maximum period in milliseconds to wait for. |
size_t descriptor_count ()
| descriptor_count |
[const]
Get the count of the descriptors that have been added.
Returns: the count of the descriptors that have been added.
void dispatch_sockevent (HANDLE hevent, XorpFd fd)
| dispatch_sockevent |
[protected]
No user-servicable parts here at the moment.