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.
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
