SYS V.3 Streams

[Sathis Menon]

>I am trying to write a streams driver and I have a question about the
>behavior of a part of it.

>I have a put and a service routine for both the read and the write
>side.  The read side seems to be working fine and I have no problems
>with it.  On the write side I put some data in a buffer, issue a
>write.  That write routine comes down into my driver where my service
>routine calls the getq routine in a while loop getting a message off
>the queue and then it calls a routine to process the message.  Once its
>processed the message, it goes back to the service routine which hangs
>in a loop until it gets a null signaling no more data to be read.  Upon
>getting the null it returns back to the user program which issues
>another write.  This second write always blocks.

	Have you checked if your queue's are getting flow
controlled? Are you really draining the data from your drivers
write queue?

>I figure it is working all right, but I am just missing something.  My
>process routine sees the data and I don't crash the system or anything
>I am just unable to service another write.  When it blocks I can abort
>and restart and it will work that one time but never a second.

>I figured that any time the user issued a write it would invoke the put
>procedure which would then invoke the service proc which would then
>call my routine to process all the data until there was no more.  The
>service routine would then would return and then the put proc would be
>sitting there waiting for more data to come down with the next write.

	When the user issues a write, it gets to the stream head
write routine, which packages this data and send it downstream (by
calling the module/driver's put procedure). The module or drivers
put procedure does whatever it wants to do with this data and can
either send it down again or queue the data on its queue (by using
putq()). The put procedure returns at that point. Before your
write system call returns to user land, streams scheduler recognizes
that there is a queue to be serviced (putq calles qenable() which does this)
and calls the queues service procedure. The service procedure typically 
sits in a while loop, extracting messages (using getq()) and processing
them, till no more messages are left *OR* it found some abnormal condition
and it cannot go on (such as flow controlled, lack of buffers etc.). When
the service procedure returns, it returns back to the STREAMS scheduler
and *NOT* to the put procedure. Thus service procedure is not an inline
procedure call.

As far as your specific problem is concerned, please send me private
mail with specif detatils (such as did your earlier write to the
device actually go through or did it get flow controlled, did you use
crash(1M) or any such debugging tool to make sure you have enough
streams buffers etc.) and I may be able to help you -

>Reggie
>{ucsd | uunet | com50}!dpmizar!reggie

Sathis Menon
School of ICS
(snm @gatech.edu or ..!attunix!akgua!gatech!snm)