Basic functions

Each STREAMS module, driver, or Stream head uses a couple of standard functions to process and move data. The modules and drivers must provide them (they are a part of the module or driver code), but they are standardized and follow some specific rules. Each module has a local put() procedure associated with it for each direction, which controls putting data (message blocks) on the appropriate input queue for this module. In other words, each module must provide a function to receive incoming data and stash Stream head Stream head it somewhere, usually on its own queue. You will find a read-side put procedure to place data on the upstream queue, and a write-side put procedure to put data on the downstream queue. One of these functions will be called (indirectly) by some other kernel piece that has data it wishes to pass to this particular module. If little or no processing is to be done, the put procedure may actually use a kernel function called putnext() to call the put procedure for the next module rather than stacking data up in its own queue. Thus, a put may call the next put in the next queue, which calls the next, and so on until either the end of the Stream is reached or something stops the progression of data. This could be either a need to do some extended processing or the fact that the next queue is full.

If the data cannot be passed directly on, for whatever reason, the put() procedure will have to place the message in the queue associated with its module and cause a service procedure to be scheduled. This service procedure will do whatever processing is necessary and will call the put() procedure for the next queue when it is done. In Solaris 2, a special kernel thread for each CPU in the system runs all the service procedures. In SunOS 4.x, procedures are run periodically: checks are made before returning to user mode to see if any service procedures are ready to be run. Service procedures might be run just before a user process resumes execution or as a part of clock-tick processing.

Flow control can be implemented if a service procedure exists for a module: a put (or a service procedure that wants to pass data onwards) will use a routine called canputnext() to see if the next queue in the stream has room, that is, if a put will work. If not, the data is stuffed back in the queue for the original module and the procedure goes away, to try again later. When the next (full) queue empties out enough to receive more data, the service procedure of the preceding queue will automatically be scheduled to run, and this time the put call should work.

Put procedures can be called from interrupt level (by a driver), by writes from a Stream head, or by service procedures. This means put procedures, as well as service procedures, cannot make any assumptions about the context in which they are run ( especially about working with the user structure). They also cannot block or sleep.