timon@sco.COM (timon) (10/28/88)
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@sco.com The Santa Cruz Operation {uunet | decvax!microsof}!sco!timon (408) 458-1422