Subject: Re: Signal Queuing

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 9 Dec 1999 16:39:42 -0600

I have further remarks below.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Thursday, December 09, 1999 10:02 AM
>
> G'Day Tom,
>
> I think your proposal has merits. Please see some clarification
> questions below.
>
> Cheers, Christian
>
        [[TomT]]  ...
> >      If
> >      a gateway is allowed to set numQueues=1 and queueLength=1,
> >      how does an MGC cope, and if it can, why do we need the
> >      mechanism?
> >      [[TomT]]
> >      Even queueLength=1 is meaningful, since it protects any signal
> >      until it completes unless the MGC turns it off explicitly.  As an
> >      alternative, we could require a minimum queue length of 2 (or
> >      more) if queuing is supported at all.
>
> [CHG] I would consider queueLength=1 does turn queuing off. You should
> get an error if you try to queue another signal while the original one
> is active.
        [[TomT]]
        That latter I agree with, but that in itself implies protection of
the first signal.  Moreover, my proposed rules for events mean that the
queued signal is immune to events not embedded with it.

> >
> >      Does the <ordered list of signals> behave as if there were
> >      individual <push> operations, one per signal?  I hope so.
> >      [[TomT]]
> >      Yes, that's how I see it.
>
> [CHG] That's how I see it to. Does this mean that everytime we apply a
>       signal that it must have a queueID?
>                   ie    (qID,(S1),[PUSH/FLUSH])
>                         (qID,(s2,s3,s4,s5),[PUSH/FLUSH])
>       I'm happy that it does. I just wanted to clarify this.
        [[TomT]]
        Absolutely not -- that would impose the book-keeping burden of your
original proposal, which I have been trying to avoid.  You only assign
queueIDs to signals you are enqueuing.  If you as vendor choose to do that
with every signal, that's your business, but it's not efficient when it's
not required.
> >
> >      How do events affect queues?
> >      [[TomT]]
> >      I would propose that events in a top-level event descriptor have
> >      no effect, unless the event has an embedded  FLUSH signal.  The
> >      basic concept is that queued signals have a special protected
> >      status.   If individual queued signals have embedded events, I
> >      suppose we should let those events have their natural effect, but
> >      only on the signal to which they are attached.
> >
> >      This may be too messy -- other people may want to comment.
>
> [CHG]  I think that the rules that you stated apply. Things are done
>        explicitely. Can you explain however the statement about queued
>        signals having embedded events?
        [[TomT]]
        Darn!  I thought we were symmetric: signals could have embedded
events to look for to turn off the signal, just as events could have
embedded signals.  I'll have to think about this one.

> >
> >      Are there completion events?
> >      [[TomT]]
> >      Seems reasonable that they could be embedded against individual
> >      signals pushed onto the queue, unless we provide equivalent
> >      semantics through a default parameter attached to every signal
> >      (not just queued ones).
> >
> >      Why would I ever put more than one entry in any queue other
> >      than one queue?  Name a circumstance where I have more than
> >      one signal playing simultaneously, and then I want to play
> >      more than one signal simultaneously, but after something I
> >      have already queued?  Can the mechanism be one queue, and
> >      multiple simultaneous single signal "registers"?
> >      [[TomT]]
> >      I'd have to think about it.  All I did was match the theoretical
> >      capability Christian and Stephen were asking for, in a simpler
> >      way than them.  (But you have to decide in advance that you want
> >      a particular signal to be handled according to queue semantics.)
>
> [CHG] We need to keep things flexible. Lets not start imposing rules
> that don't need to be there.
        [[TomT]]
        Not sure what this comment implies, but I mean what I said.  You
decide in advance whether a signal goes on a queue, and you can't change
your mind later if your initial decision is not to queue it.

> >
> >      Suggest a syntax.  Something like Signal=<queue>{[FLUSH,]
> >      sig1, sig2,...}?
> >      [[TomT]]
> >      Looks possible, though I'd put it down a level
> >      i.e. Signal={sig1, <queue>{[FLUSH,] sig2, sig3,...}   }
>
> [CHG] Where does the streamID come into play?
>        Signal =StreamID{<queue>,sig1..,[FLUSH]}     or
>        Signal ={<queue>,StreamID{sig1..,[FLUSH]}}
>       Do we assume sig1 in your example above is default <queue>?
        [[TomT]]
        No.  I show sig1 standing alone because I don't want it queued.
        StreamID is a parameter of a signal, so my example above with
explicit streamIDs becomes
        Signal={sig1{streamID=1}, <queue>{FLUSH, sig2{streamID=2},
sig3{streamID=1}...}  }

> >
> >      How do I handle on/off signals?
> >      [[TomT]]
> >      Don't put them into a queue.  Alternatively, allow them in, but
> >      only if they have embedded events to stop them.  I don't like
> >      this alternative myself -- seems too dangerous.
> [CHG]  Allow them. People should be aware of the consequences. OO makes
> sense if its the last one in the queue.
        [[TomT]]
        But if another entry gets added later it won't be the last one in
the queue any longer.

        [[TomT]]  ...

---

From: Christian Groves <[email-masked]>
Date: Mon, 13 Dec 1999 14:49:59 +0100

G'Day Tom,

Please see [CHG] below.

Cheers, Christian
Tom-PT Taylor wrote:
>      That latter I agree with, but that in itself implies protection
>      of the first signal.  Moreover, my proposed rules for events mean
>      that the queued signal is immune to events not embedded with it.
[CHG] To me then you see a signal with queueLength=1 as being the same
as a BRIEF signal today. I don't agree with this. There has to be a
limit of BRIEF signals which can be queued and this is specified by
queueLength either we have queuing of some sort (brief included) or we
don't have any.

<..snip..>