Dave, On Tue, 08 Jun 2004, Dave Grothe wrote:
> > At 11:16 PM 6/7/2004, Brian F. G. Bidulock wrote: > > UnixWare: > "qprocsoff disabled the put(D2str) and srv(D2str) routines of the > driver or > module whose read queue is pointed to by rq. It removes the > queue's service > routines from the list of service routines to be run and waits > until any > concurrent put or srv procedures are finished. When the routines > are > disabled in a module, messages flow around the module as if it > were not > present in the stream. > > Interesting semantics. They don't say what happens to the messages if > the routines are for a driver rather than a pushable module. > > qprocsoff must be called by the close(D2str) routine of a driver > or module > before deallocating any resources on which the driver/module's > put() and > srv() routines depend. Drivers or modules should call qprocsoff > exactly > once to disable put and service procedures. One additional > effect of > calling qprocsoff is that both the read and write queues are > flushed." > > My point precisely. The routine is called exactly once, from the > driver/module close routine. > If the module's close routine is being called it is because the stream > is being dismantled, so there is no point in jumping through hoops to > route messages around the module. > The other possibility is that an I_POP is being executed, which I hope > has enough lock protection that messages cannot flow into the module > during this operation. It does not. qdetach waits without locks held allowing a driver from below to continue to call putnext() or qreply() while the module is popping. My point in the first place. > As I said before, "Works as implemented." Another way of saying BUG? --brian > -- Dave -- 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
