Sure! See attached the original note to the libevent folks
--- Begin Message ---
Hi folks
I'm working with priorities in events using libevent 2.0.13. Since I'm not
using the most current release, I thought I'd ask about a behavior we are
seeing that might be a potential bug.
I have attached a simple reproducer of the problem. In short, suppose I have
setup 8 priorities for my event base. I then execute an event at priority 4. In
that callback, I setup and activate two new events - first one at priority 4,
and then another at priority 0. We then cycle back through the event loop.
Given the prioritized event base, I would expect the event at priority 0 to be
called back first. However, this isn't what happens. Instead, the first event
to be defined (in this case, the one at priority 4) is called back first.
Is this the expected behavior? Can someone point me to the error in this
reproducer that might be causing the problem?
FWIW: I found that if I adjust the initial event's priority to something
different than 4 (i.e., the level of the next event to be defined), then I get
the expected behavior. So it appears that the problem is that when we return to
the loop, we trigger any pending event of the same priority as the one we were
in, instead of looping around to check the highest priority first.
Thanks
Ralph
evpri-test2.c
Description: Binary data
--- End Message ---
On May 9, 2012, at 7:45 AM, Josh Hursey wrote:
> Ralph,
>
> Can you point me to the small reproducer for the libevent bug that was
> fixed? I'm just curious.
>
> Thanks,
> Josh
>
> On Fri, May 4, 2012 at 4:09 PM, Ralph Castain <r...@open-mpi.org> wrote:
>> FYI: 2.0.19-stable was released yesterday. I have a Mercurial repo all set
>> to go:
>>
>> https://bitbucket.org/rhc/ompi-libevent2019
>>
>> Please check it out - timeout is now set for May 11th.
>>
>> Thanks
>> Ralph
>>
>> On May 1, 2012, at 8:38 AM, Ralph Castain wrote:
>>
>>> WHAT: Update libevent to 2.0.19 release
>>>
>>> WHEN: As soon as it is released, expected around May 11
>>>
>>> WHY: The 2.0.19 release contains a critical fix to a bug I recently
>>> discovered in the libevent 2.0.x series
>>>
>>>
>>> Details:
>>> I discovered a bug in libevent over the last few days that causes it to
>>> unexpectedly "invert" event priorities. It is a slightly subtle bug, but we
>>> were able to provide a simple reproducer and so the libevent folks were
>>> able to quickly implement a fix.
>>>
>>> Stated simply, if you were in an event of a given priority and activated an
>>> event of higher priority, that new event would not get serviced if any
>>> event of the current priority were to become active prior to leaving the
>>> current event. In other words, libevent would service all active events of
>>> the current priority before even looking to see if a higher priority event
>>> was active.
>>>
>>> The patch adds the following logic to event_active:
>>>
>>>> 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>
>>>
>>>
>>> Thus, a rescan only occurs if a higher priority event becomes active during
>>> an event of lower priority. Unfortunately, ORTE relies on this behavior to
>>> handle errors - without the change, an error reported in a message from a
>>> daemon (for example) cannot be serviced until ALL messages that arrive
>>> during the processing of the message have been handled. In the case of a
>>> large cluster that is receiving a long list of messages, this prevents the
>>> error from being handled for quite some time.
>>>
>>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
>
> --
> Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> http://users.nccs.gov/~jjhursey
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
