--- Dave Grothe <[EMAIL PROTECTED]> wrote: > Works as implemented. > > I'm not concerned about qprocsoff(), a routine that is called from a > driver's close routine. LiS does not enter a drivers put or srv routine > while its close routine is running and I can't imagine any STREAMS > semantics that says otherwise. >
Just for the record, HPUX works the same way as LiS in that put and service routines cannot run at the same time as the close routine. qprocsoff() is just #define qprocsoff in HPUX 10.20, 11.0 and 11.11. SUPER-UX? Come on, who worries about SUPER-UX compatibility in 2004? Brian, there is no reason to be so snotty about this stuff. If you have a problem with the way that stuff works, then submit a patch and let everyone have at it. Your constant superior attitude really gets tiresome... -dan The above is my opinion and does not represent the thoughts or opinions of my employer, Adax Inc. > Solaris' documentation for qprocsoff() certainly does not encourage its use > > anywhere other than in the close routine. > > -- Dave > > At 05:23 PM 6/5/2004, Brian F. G. Bidulock wrote: > >Dave, > > > >appq is a simple LiS wrapper for insq. It is never used within LiS. > There is > >no documented equivalent in other implementations. It could return int > quite > >easily and should for parallels to insq. > > > >There are some other problems with this set of functions. Each of putq, > >putbq, insq and appq will fail when QPROCSOFF flag is set. This is > >inconsistent with the description of qprocsoff() for SVR 4.2 MP, Solaris, > >SUPER-UX, UnixWare, OSF/1, HP-UX, and possibly others. qprocsoff() is > only > >supposed to inhibit entering a queue's put and service procedures after > return > >from the call. Queue put and service procedures in execution are supposed > to > >be unaffected, and qprocsoff() certainly is not supposed to affect putq(), > >putbq() or insq() to the effect of causing the discard of STREAMS > messages. > > > >This is also true for a closing queue. > > > >Closing pushed modules are supposed to be effectively bypassed before > queue > >flushing by the call to qprocsoff(). This can be accomplished by > bypassing > >the module with q->q_next pointers. On MP systems, the stream needs to be > >frozen by the STREAMS executive while these pointers are adjusted. > > > >On MP systems, putq() and pubq() are only supposed to be called from > within a > >queue procedure for the queue that is referenced by the function call. > >putnext() and qreply() are for referencing adjacent queues on the stream. > >putq(), putbq() and insq() also examine QCLOSING, however, an implicit or > >explict qprocsoff() is supposed to be peformed before the queues close > >procedure returns. > > > >But putnext() and qreply() use lis_safe_putmsg() which also frees the > message > >when qprocsoff() has been called (QPROCSOFF flag set). > > > >So, here's the problem, by inspection: I have a running stream with a > module > >pushed. I detect that the module is no longer required and I_POP it from > the > >stream. During the time that the QCLOSING or QPROCSOFF flags are set all > >message sent upstream by the driver are discarded by putnext() and > qreply(). > >Also, if the module's put or service proceedure is running when qprocsoff > is > >called, putq() and putbq() will return failure and there is little choice > but > >to discard the message. I expect these messages to, instead, be delivered > to > >the stream head, but they have been lost. > > > >So, the entire set is still appears flakey. In the 10 lines or so of each > >function, there appears to be about 3 defects. It is frustrations like > this > >that push me away from LiS. > > > >--brian > > > >On Fri, 04 Jun 2004, Dave Grothe wrote: > > > > > > > > At 11:25 AM 6/4/2004, Brian F. G. Bidulock wrote: > > > > > > Eugene, > > > These bugs have been documented for some time in the manpages. > Why > > > not fix > > > insq and appq while your at it? insq improperly frees the > message > > > as well. > > > > > > OK. Fixed. I don't know where appq() came from. It is not > present > > > in Solaris or in the SVR4 STREAMS programming guide. Anyway, > it > > > returns void so I made it free the message if anything fails. > > > > > > Also, watch out for putnext and qreply that can also fail > silently > > > and free > > > the message (or not). > > > > > > Nothing to watch out for. These are void functions and always > dispose > > > of the message either by calling the appropriate driver put routine > or > > > freeing the message if something is wrong (q pointer NULL, q > put > > > function pointer NULL, etc). > > > -- 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 > _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
