[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Event priorities



On Mon, Apr 30, 2012 at 3:53 PM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
> 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.

It's  not the cause of your problem, but "event_add()"ing these events
is nonsensical.  If an event has fd -1, it is meaningless (and
undefined!) to give it EV_READ or EV_WRITE and assign.  It could cause
bugs down the line if that's your standard practice.

Looking at the issue, I think the problem occurs when you use
event_active() to activate another event of priority equal to the
currently executing event: since the event will happen in the
currently executing instance of the event loop rather than the next
one, it'll keep executing all events of that priority, including the
new one, before it scans for new events and executes higher priority
events again.

Or from another point of view, the problem is that using
event_active() on a higher-priority event doesn't tell event to stop
executing events at the current priority and go to the next event loop
iteration.

Option 1:  Call this a bug. Say that if you use event_active() to
activate an event of higher (that is, numerically lower) priority than
the currently executing event, the event loop needs to check for new
events and then execute higher-priority events.

Option 1a: apply the fix in 2.0, since it's probably right.
Option 1b: apply the fix in 2.1, since it might potentially break
something if anybody was relying on the old behavior.

Option 2: Call this a regrettable wart, but say that option 1 is too
destabilizing. Add an event_base_loopcontinue() that causes libevent
to re-scan and start its dispatch phase again.

Option 3: Call this an intended feature; tell everybody that they need
to use event_config_set_max_dispatch_interval() as a workaround.

Thoughts?

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.