dan_gora, I wasn't trying to act superior. I'm sorry if it comes across that way.
HPUX: "SVR4 MP providse qprocson and qprocsoff, which on a multiprocessor system allows a module's put and service routines to run concurrently with open and close. STREAMS/UX does not allow this much parallelims. A module's or driver's put and service routines cannot run at the same time as the open or close. Although STREAMS/UX does not run the put or service routine in parallel with the open or close, it does queue any requests to run the put or service routine. STREAMS/UX will process these when open finishes. Also, if open or close sleeps, STREAMS/UX can run the put and service routines while open or close are sleeeping. However, a put or service routine cannot do the wakeup on a sleeping open or close. STREAMS/UX provides stubs which are no-ops for qprocson and qprocsoff to make porting easier." "... For HP-UX STREAMS, yoy do not need to call qprocson or qprocsoff as you do for SVR4 MP STREAMS. ..." Solaris: "qprocson() enables the put and servce routines of the driver or module whose read queue is pointed to by q. Threads cannot enter the module instance through the put and service routines while they are disabled. qprocson() must be called by the open routine of a driver or modules before returning, and after any initialization necessary for the proper functioning of the put and service routines. qprocson() must be called before calling put(9F), putnext(9F), qbufcall(9F), qtimeout(9F), qwait(9F), or qwait_sig(9F). qprocsoff() must be called by the close routine of a driver or module before returning, and before deallocating any resources necessary for the proper functioning of the put and service routines. It also removes the queue's service routines from the service queue, and blocks until any pending service processing completes. The module or driver instance is guaranteed to be single-threaded before qprocson() is called and after qprocsoff() is called, except for threads executing asynchronous events such as interrupt handlers and callbacks, which must be handled separately." SUPER-UX: "qprocsoff disables the put and service routines of the driver or moudle whose read queue is pointer 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 service routines are finished. When the routines are disabled in a module, messages flow around the module as if it were not present in the stream. qprocsoff must be called by the close(D2) routine of a driver or module before deallocating any resources on which the driver/module's put and service routines depend. Drivers or modules should call qprocsoff exactly once to disable put and service procedures. On additional effect of calling qprocsoff is that both the read and write queues are flushed." 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. 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." Now, it strikes me that Eugene's problem is that LiS has no equivalent of the streams_put() function that appears in HP-UX. HP-UX will defer a streams_put() into the STREAMS/UX environment, where it cannot run concurrent with a open() or close() procedure in the stream. STREAMS/UX can ensure that no put() or srv() procedure runs concurrent with open() or close() because streams_put() exists to defer put() procedures and force entry into the framework. My problem is that LiS does not exhibit the other behavior of SVR4 MP systems in that "when routines are disabled in a module, messages flow around the module as if it were not present in the stream". Certainly, putnext() and qreply() should not be discarding messages on qprocsoff() which the the problem behavior. No, LiS does not enter the put() or srv() procedure while QCLOSING or QPROCSOFF, but it should not discard messages, but pass them around the module. Now, its clear that lis_qdetach() unlocks the queues after setting QPROCSOFF flag, so that putnext() and qreply() indeed will discard messages when called downstream of a closing module. I agree that it would be difficult to repair this without rewriting large portions of LiS 2.16. I will propose a patch: a very large one that replaces LiS. --brian On Mon, 07 Jun 2004, dan_gora wrote: > > --- 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. > > > -- 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
