Re: Possible putq incompatibility

[David Grothe]

Brian:

In answer to your questions:

1. I am not concerned about the performance impact of passing file/line numbers to various routines.  I am more concerned about the ability to troubleshoot code that exhibits problems in production settings.  I learned decades ago that if you inhibit the trace tables in production code, then *when* problems occur and you enable the tracing, execution timing changes and half the time the symptom disappears.  Then you are stuck.
2. The inability to use "putq" as a "put" procedure is a different story.  That should be allowed.

At the moment I don't see a good way around this problem.  Does anybody else?

The original SVR4 definition of putnext was just a macro that blindly called the put procedure in the next module without checking for any valid conditions.  I have not tried coding a STREAMS driver with a NULL put procedure and then attempting a putnext into it.  I suspect that it would panic UnixWare 7 and maybe Solaris.  Would someone like to try it?

I do like your workaround.

-- Dave

"Brian F. G. Bidulock" wrote:

I have stumbled across a possible incompatibility between LiS and
SVR4.2 STREAMS.  It relates to the putq macro expansion.  In SVR4.2
STREAMS I can do the following:

    static struct qinit mod_rinit =
    {
        putq,
        mod_rsrv,
        NULL,
        NULL,
        NULL,
        &mod_minfo,
        NULL
    };

so that any upper module calling putnext(q, mp) will result in
putq(q->q_next, mp).  gcc properly warns on the above because putq
is a macro which expands to lis_putq which has extra debugging
arguments.

That the above should be possible is indicated by the following
quote from the Magic Garden:

    "There are two type of module.  The first queues all messages,
    and only processes them via its `service' procedure.  Such
    modules have `putq()' specified as their `put' procedures..."

I cannot use:

    static struct qinit mod_rinit =
    {
        NULL,
        mod_rsrv,
        NULL,
        NULL,
        NULL,
        &mod_minfo,
        NULL
    };

because an examination of lis_safe_putnext reveals that it does not
check qi_put for NULL unless LIS_DEBUG_SAFE is on, and even then
it just logs and discards the message.

Because I cannot guarantee that an upstream module will not call
putnext, I am forced to use:

    static void mod_rput(queue_t *q, mblk_t *mp) { putq(q, mp); }

    static struct qinit mod_rinit =
    {
        mod_putq,
        mod_rsrv,
        NULL,
        NULL,
        NULL,
        &mod_minfo,
        NULL
    };

Has any consideration been given for the compatibility and
performance impact that all the filename and line number
argument passing and linkages have on a running module?

Is anyone interested in a version which is tuned for production
performance rather than development debugging?

--
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 �
Web archives for lists can be found at http://gsyc.escet.urjc.es/lists