I/O Event Semantics

Socket I/O can proceed only when certain I/O conditions exist. To receive notification of those conditions, programs can create I/O events, and define callback functions to read or write when sockets are ready.

When a program registers event interest on an I/O socket, the specified condition may occur repeatedly; each time the program can read or write one or more bytes on that socket, the event driver queues the I/O event.

When a program creates an I/O event, the creation call activates the event—that is, it requests notification from the operating system when the corresponding I/O situation occurs. When the specified condition occurs, Rendezvous software deactivates the event, and places the event object on its event queue. When the callback function returns, Rendezvous software automatically reactivates the event. In this way, only one reference to the I/O event can appear in a queue at any moment in time. (References to several I/O events can appear simultaneously, but two references to the same event cannot appear at the same time.) I/O Event Activation and Dispatch illustrates that Rendezvous software temporarily deactivates the I/O event from the time it enters the queue until its callback function returns.

Figure 22: I/O Event Activation and Dispatch

I/O Event Creation

C

tibrvEvent_CreateIO()

C++

TibrvIOEvent::create()

Java

I/O events are not available with Java.

.NET

I/O events are not available with .NET.

Operating System I/O Semantics

The semantics of all I/O conditions depend on the I/O semantics of the underlying operating system and its event manager. Rendezvous software does not change those semantics.

I/O events trigger when the operating system reports that an I/O condition on a monitored socket would succeed (transfer at least one byte without blocking).

For example, write events depend on the state of the socket—it must be write-available. That is, on each pass through the event driver’s loop, the socket can accept one or more bytes.

Blocking I/O Calls

Rendezvous software cannot guarantee that a subsequent I/O call will not block.

I/O conditions are not necessarily static. Event stealing or write overload can change the I/O condition before the callback function runs.

As an example of event stealing, consider an I/O event indicating that a particular socket has data available for reading. Another thread or process could read the data from that socket before the I/O event callback function can read the socket. In that case, a read call could indeed block.

Availability

Socket I/O is available in the C and C++ interfaces, but not in the Java interface.