Section 18.6. Synchronous STREAMS


18.6. Synchronous STREAMS

Synchronous STREAMS extends the traditional STREAMS interface for message passing and processing. It was originally added as part of the combined copy and checksum effort. It offers a way for the entry point of the module or driver to be called synchronously with respect to a user I/O request. In traditional STREAMS, the stream head is the synchronous barrier for such requests. Synchronous STREAMS provides a mechanism to move this barrier from the stream head to a module below.

18.6.1. TCP Synchronous STREAMS

The TCP implementation of synchronous STREAMS before the Solaris 10 release was complicated by several factors. A major factor was the combined checksum and copyin/copyout operations. In Solaris 10, TCP does not depend on checksum during copyin/copyout, so the mechanism was greatly simplified for use with loopback TCP and UDP on the read side. The synchronous STREAMS entry points are called during requests such as read(2) or recv(3SOCKET). Instead of sending the data upstream with putnext(9F), these modules queue the data in their internal receive queues and enable the send thread to return sooner. This avoids a call strrput() to queue the data at the stream head from within the send thread context, thus allowing better dynamics. In turn, the amount of time taken to queue and signal/poll-notify the receiving application is reduced, so the send thread returns faster to do further work; things are less serialized than before.

Each time data arrives, the transport module schedules the application to retrieve it. If the application is currently blocked (sleeping) during a read operation, it is unblocked so that it can resume execution. Unblocking is achieved by a call to STR WAKEUP SET() on the stream. Likewise, when no more data is available for the application, the transport module calls STR WAKEUP CLEAR() to block the application again during the next read attempt. Any new data that arrives before then will override this state and cause subsequent read operations to proceed.

An application can also be blocked in poll(2) until a read event occurs, or it may be waiting for a SIGPOLL or SIGIO signal if the socket used is nonblocking. Because of this, the transport module delivers the event notification or signals the application each time it receives data. It does this by calling STR SENDSIG() on the corresponding stream.

As part of the read operation, the transport module delivers data to the application by returning it from its read-side synchronous STREAMS entry point. In the case of loopback TCP, the synchronous STREAMS read entry point returns the entire content (byte stream) of its receive queue to the stream head. Any remaining data is requeued at the stream head, awaiting the next read. For UDP, the read entry point returns only one message (datagram) at a time.

18.6.2. STREAMS Fallback

By default, direct transmission and read-side synchronous STREAMS optimizations are enabled for all UDP and loopback TCP sockets when sockfs is directly above the corresponding transport module. Several cases require these features to be disabled. When such a case occurs, message exchange between sockfs and the transport module must then be done through putnext(9F). The cases are described as follows.

  • Intermediate module. A module is configured to be autopushed at open time on top of the transport module by autopush(1M) or is I PUSH'd on a socket by ioctl(2).

  • Stream conversion. The imaginary sockmod module is I_POP'd from a socket, causing it to be converted from a socket endpoint to a device stream. (Note that I INSERT or I REMOVE ioctl is not permitted on a socket endpoint, and therefore a fallback is not required to handle it.)

If a fallback is required, sockfs notifies the transport module that direct mode is disabled. The notification is sent down by the sockfs module in the form of an ioctl message, which indicates to the transport module that putnext(9F) must now be used to deliver data upstream. This scheme enables data to flow through the intermediate module and provides compatibility with device stream semantics.




SolarisT Internals. Solaris 10 and OpenSolaris Kernel Architecture
Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture (2nd Edition)
ISBN: 0131482092
EAN: 2147483647
Year: 2004
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net