Subject: Completion Event for signal timeout

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 21 Jan 2000 17:43:49 -0500

It has been suggested that we have a way to find out that a signal
(or signal list) of type TIMEOUT have an event which could be
triggered when the timer expired.  We can generalize this to
completion of any signal.

I propose that we define an event in generic called sc, signal completion,
which has a parameter, a list of the names of events to
report completion.

The alternative is to add syntax to signals.  I think it's better
to make it an event - it looks like an event, acts like an event,
it is an event.

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 24 Jan 2000 10:45:38 -0500

What I've realized, thinking things over, is that we have to define two
different things: how to activate reporting of the completion event, and how
to report it.  The optional signal parameter activates it.  A generic
completion event would report it.  There are two cases: reporting a simple
signal completion, and reporting completion of a signal list.  The first is
all we really need, since the second can be achieved by reporting the
completion of the last signal in the list.

> -----Original Message-----
> From: John Segers [SMTP:[email-masked]]
> Sent: Monday, January 24, 2000 7:09 AM
> To:   [email-masked]
> Subject:      Re: Completion Event for signal timeout
>
> I'll second that.  If it's an event, I don't see how we can get
> granularity finer than signals descriptor level.
>
> John
>
> > Tom-PT Taylor wrote:
> >
> > If it's an optional parameter for signals it makes life a lot easier
> > -- you can say exactly which signal you want to get the report for
> > with no fuss.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:[email-masked]]
> >      Sent:   Friday, January 21, 2000 5:44 PM
> >      To:     [email-masked]
> >      Subject:        Completion Event for signal timeout
> >
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jan 2000 06:50:21 -0500

Sorry, seems like it got stuck in my outbox!

It's messy to have event enables in two places.  As an example of the
problems, what
do you do with the Event Buffer?

The syntax I imagine is:
..Signal(cs/rt{SignalType=TimeOut, Duration=4000}},Events{g/st{cs/rt}}

That's pretty low fuss, says exactly which signals, etc.

Brian

> From: John Segers [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 3:02 AM
> To: [email-masked]
> Cc: Rosen, Brian
> Brian,
> I tried finding your proposal, but all I found was "I propose that we
> define an event in generic called sc, signal completion, which has a
> parameter, a list of the names of events to report completion." (in a
> message you sent to the list last Friday).  Can you repost
> the proposal
> you're talking about?
>
> John
>
> "Rosen, Brian" wrote:
> >
> > Does my proposal accomplish the goals?  It seems to me that
> it does, and
> > avoids a couple of problems alluded to earlier (Event Buffer).
> >
> > Brian
> >
> > > From: John Segers [mailto:[email-masked]]
> > > To: [email-masked]
> > > >      I propose that we define an event in generic
> called sc, signal
> > > >      completion,