incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Morel <matthieu.mo...@gmail.com>
Subject Re: Dynamic processEvent method overloading
Date Thu, 13 Oct 2011 14:21:34 GMT
On Wed, Oct 12, 2011 at 8:18 PM, Leo Neumeyer <leoneumeyer@gmail.com> wrote:

>
> ...
>
> >
> >> A few thoughts:
> >>
> >> Input/Output names may not make a lot of sense any longer. What about
> >> changing to the following:
> >>
> >> processEvent(Event1 event) with any of the synchronous configurations.
> >>
> >> timerTask()  called when there is a timer task configured.
> >>
> >> The timer task needs to be synchronized with the processEvent method
> >> (unless the PE has a @ThreadSafe annotation), we can keep the internal
> dummy
> >> event to synchronize but call timerTask() without an Event instead. I'm
> sure
> >> there are other ways of doing this.
> >>
> >> Does this make sense? We need to think a bit.
> >>
> >
> > Indeed, we lose some consistency in the API by handling output triggers
> in 2
> > different methods, depending on the trigger (event count based or timer
> > based)
> >
> > The original design (as described in the S4 paper) uses a "processEvent"
> > method for input events and an "output" method for triggered outputs. Why
> > not just keep that design? For the dynamic overload dispatcher, that
> would
> > just mean removing the code for "processOutputEvent".
> >
>
> Not sure I understand what you propose. I think we are saying the same:
>
> the processEvent() method can be configured to be triggered:
>
> - on every matching input event
> - on every N matching input events
> - on input event if time since last event is greater than delta
>

This is a part which is not clear to me. My understanding was that the
output method might be triggered at periodic intervals, not the input
processing method. You seem to want to mix both methods, which is a bit
confusing to me. But it is also possible.



>
> We still need another method for periodic tasks, maybe a good name is
> periodicTask()
>

is it a periodic task that we need (and we may), or is it a periodically
invokable output method?



> This method is synchronized with processEvent() (unless PS is
> @ThreadSafe) and it doesn't need to pass an event (because it is
> asynchronous).
>
> So it's not just removing processOutputEvent(), we need an additional
> method for periodic tasks that is synchronized with processEvent().
>

That's the "output" method in the S4 paper, no?



Matthieu

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message