If you're right that something besides Magic Garden says to call only once and that must be the read side, then I'll agree with you. I just wasn't willing to accept MG as authoritative.
The code does always check the read side first, by the way, whether called with the read queue or the write queue. So, zeroing do_close would be a good compromise. Also good if some other system is not as strict about read-side-only, but still wants only a single call.
-John
Brian F. G. Bidulock wrote:
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
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
