John, On Fri, 10 Oct 2003, John A. Boyd Jr. wrote:
> Dave G. - how about checking to see if they're the same, if both are > set, and if they are, call only one? But otherwise, call whatever is > set, which may be both? > > I agree with you otherwise, though; I'd prefer to leave it as is. Why? When it goes against documented STREAMS behavior? On the other hand, what about qi_qopen()? Why are you not calling both qopens? One with the read queue pointer and the other with ther write? Because its not done that way, of course. And what is true for qopen() is true for qclose() in this case. --brian > > -John > > David Lehmann wrote: > > David Grothe wrote: > > > >> David: > >> > >> I think I see what is going on. Consider the following lines from the > >> trace: > >> ... > >> Queues come in pairs. This loop is examining each queue of the pair > >> and calling the close routine for whichever queue has a pointer to a > >> close routine. Apparently your qinfo structure for your module has a > >> pointer to the close routine for both the read and write queues. It > >> is conventional to only provide open/close routine pointers for the > >> read queue. > >> > >> I think if you change your qinit structure the problem will go away. > > > > > > Maybe so, but this is the same code that Solaris uses. > > My understanding is that close should be called once and only once > > for the queue pair. Maybe you should take John's suggestion and > > set do_close to zero after executing the close routine once. > > > > > _______________________________________________ > Linux-streams mailing list > [EMAIL PROTECTED] > http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams -- Brian F. G. Bidulock � The reasonable man adapts himself to the � [EMAIL PROTECTED] � world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
