On 12/04/2012 01:59 AM, Henrik Nordström wrote:
> mån 2012-12-03 klockan 23:12 -0700 skrev Alex Rousskov:
>
>> BTW, once zero-delay events are removed from the code, the event queue
>> will no longer need to be a part of the wasActivity loop and the loop
>> will disappear.
>
> Note: Legacy zero-delay addEvent events are meant to be called once per
> comm loop. Not immediately/chained. This is by design.
There are several ways to interpret the designer intent when looking at
undocumented code. I cannot say whether all of the currently remaining
zero-delay events use your interpretation, but I am certain that I have
added zero-delay events in the past that used a comm-independent
interpretation ("get me out of this deeply nested set of calls but
resume work ASAP"). And, IMO, that is actually the right definition for
the reasons discussed in my response to Amos email.
> heavy events in the context of addEvent events are really "this is very
> heavy", and there is only allowed to be one and only one heavy event per
> comm invocation. If there is multiple heavy jobs competing for time they
> are meant to get scheduled in a round-robin fashion with comm inbetween
> each.
Agreed. Both patches support that AFAICT.
Alex.
Received on Tue Dec 04 2012 - 15:39:56 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 05 2012 - 12:00:09 MST