Asserting we're not freeing active event #1642
Conversation
Ok
Ok
Ok
Not possible, since if you have EV_LIST, then event_assign() is called and base should be set, otherwise it cannot be run
This is also should not be possible, since only EVLIST_ACTIVE should be triggered from event_process_active_single_queue We can add an assert here for base and EVLIST_ACTIVE
So this should not be possible. |
Coeur
force-pushed
the
coeur/EV_CLOSURE_EVENT_FINALIZE_FREE
branch
from
835888f
to
ae17ef2
Compare
|
Coeur
force-pushed
the
coeur/EV_CLOSURE_EVENT_FINALIZE_FREE
branch
from
ae17ef2
to
19deb9f
Compare
Coeur
changed the title
Coeur
force-pushed
the
coeur/EV_CLOSURE_EVENT_FINALIZE_FREE
branch
from
19deb9f
to
83c5750
Compare
…ue() It should not be possible, since only EVLIST_ACTIVE should be triggered from event_process_active_single_queue, but adding assert will not hurt.
azat
force-pushed
the
coeur/EV_CLOSURE_EVENT_FINALIZE_FREE
branch
from
83c5750
to
66ee086
Compare
|
LGTM, thanks! P.S. next time please try to fit commit subject into 80 chars (I've adjusted the commit messages by myself this time) |
Fix #1638.
Although, could be done differently if you have suggestions.
Conditions:
evcb_flags & EVLIST_INITto setev! (ev->ev_events & EV_PERSIST)to skipevent_queue_remove_active! (ev->ev_flags & EVLIST_FINALIZING)to skipevent_queue_remove_activeev->ev_base == NULLto skipevent_queue_remove_activeinevent_del_nolock_! (ev->ev_flags & EVLIST_ACTIVE)to skipevent_queue_remove_activeinevent_del_nolock_evcb->evcb_closure == EV_CLOSURE_EVENT_FINALIZE_FREEfor the free to occur! base->event_breakto continue the loop! base->event_continueto continue the loopWhen those conditions are met, we free an event without removing it from the queue.
If you know that one of those conditions is strictly impossible, then we could add a specific assert instead my current proposal.
Another alternative to "not free" when it's in the queue, is to remove that event from the queue when above conditions arise, but I wouldn't know the side effects of such change.