Re: [Libevent-users] Event priorities

[Ralph Castain <rhc@xxxxxxxxxxxx>]

On Apr 30, 2012, at 2:30 PM, Nick Mathewson wrote:

> 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.

Thanks - I'll correct that.

> 
> 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.

I think either of these would be acceptable, and agree that this feels like a bug to me. If 2.1 can be released soon as other than alpha, I'm happy to bump up to that level.

> 
> 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.

Just to be clear in my own mind: I gather we would call this when activating an event of the same priority as the one we are in, thus telling libevent to rescan when we call event_loop again? If so, then that might be okay, though I suspect the only way to really make it work in production is to always call loopcontinue if you add an event while inside an event (just in case the priorities match). Doesn't seem as clean as Option 1.

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

Feels a little strange, but I could live with it - assuming 2.1-alpha bumps up soon. Still prefer option 1 (at least 1b) as I think it truly is a bug.

HTH
Ralph

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

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