On Apr 30, 2012, at 5:10 PM, Nick Mathewson wrote:
> On Mon, Apr 30, 2012 at 6:45 PM, Ralph Castain <r...@open-mpi.org> wrote:
> [...]
>> I'll take a look at your branch, but had some further thoughts in the
>> interim. Would a more optimal option be to add the following logic to
>> event_priority_set:
>>
>> event_priority_set(ev, pri) {
>> IF <I am in an event> AND
>> IF <ev->base> EQ <current-base> AND
>> IF <pri> LT <current-pri> THEN
>> <rescan queues on next loop>
>>
>> In other words, only rescan and start the dispatch phase if the priority of
>> the new event is higher (less-than) that of the current event. If not, then
>> just proceed as we currently do. This avoid unnecessarily restarting the
>> dispatch phase when lower priority events are defined.
>>
>
> That doesn't really make sense; event_priority_set is used to set up
> the event, not to add it to the active queue. You'd want logic like
> this in event_active(), not event_priority_set.
Agreed - your approach is definitely better, IMO. I was glad to see you had
similar thoughts.
The branch looks like it does the trick, and I like that it also does not force
the re-scan unless the newly activated event is a higher priority.
+1 from me.
Meantime, I gather this was against the current 2.0 trunk as opposed to the
2.0.18 release - I might consider bumping up to it if you think a 2.0.19 is a
ways off.
>
> (This is, btw, more or less the logic in my branch.)
>
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
