Menu
▾
▴
#73 Alter logic when adding delete events to the changelist
This is a more speculative patch that follows on from my previous 100% cpu usage patch to event_changelist_del
As far as I can see, the add,delete, dispatch case described in the original comment will never happen. The recorded change is a single operation, not a queue. This seems to leave actions to delete events that never existed as the real targets for converting to no-ops (although it looks like both epoll and kqueue deal with this case possibly making the whole check redundant).
I've changed the logic in event_changelist_del again... this time it only uses change->old_events when deciding whether to convert a delete into a no-op.
I haven't done anything about the case where we try to add an event that already exists.
I like this one, but it doesn't fix an actual bug, I think: it only simplifies the existing logic. Is that right? If so, it should wait until Libevent 2.1, since we're trying to minimize non-bugfix changes in Libevent 2.0.
(Libevent 2.1 should fork off some time in the next month or so.)
Other than that, this patch _does_ look right, and should go in.
Merged as the first patch in Libevent 2.1.0-alpha-dev.