STREAMS: problem of listen connect.indication in module

[timon]

in resp to: uunet!husc6!bbn!rochester!ritcv!cci632!ccicpg!yarran

>					...	  The problem arises on whether 
>the listening module should accept the call on the listening queue or create
>a new queue to accept the call.  In the former case, the listening queue will
>be changed into data transfer state and no more connect.indication primitives
>can be put into the queue anymore, until the user process finally receives the
>call and create a second queue to accept the call (by using ioctl I_FDINSERT).
>During this period, all the following connect.indications have to be either
>queued in the lower layer module/driver or be discarded. ...

it seems to me you are confused on an issue here.  Connection indications
will NOT just come upstream of their own accord.  A process must first
post a passive open to a stream before an indication comes upstream.
Therefore, you would never have the case that the stream driver (or module)
below you wanted to send you a connection indication that you were not ready
to receive.

>... unfortunately, AT&T did not supply any STREAMS function call  for creating
>a queue between modules.  Of course, you can probably avoid this case by
>implementing it as a mux driver and pre-allocate all the queues. But this  
>approach is undocumented and seems violate the original intent of mux driver.
>

the second concept that seems to be getting confused here pertains to the
use of queues.  The reason for having queues is so that, if you cannot
send a message to the next module along the stream, you can just keep
the message on our own queue until the next module along the line is
ready to accept it.  The classic example is where you check to see if the
next queue is accepting messages (using canput).  If you can send the 
msg - do so.  If you cannot send the msg - put it back on the front of
your OWN queue (putbq).  When the next queue along the stream becomes 
re-enabled your service routine will automatically be scheduled to run.  
At this point the your service routine will retry - and the first message
it will get of its own queue will be the one for which processing just
failed.

timon
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Timon Sloane				timon at sco.com
The Santa Cruz Operation		{uunet | decvax!microsof}!sco!timon
					(408) 458-1422