Page MenuHomeFreeBSD

Restore the ability to deregister an eventhandler callback from within the callback.
ClosedPublic

Authored by ian on Oct 1 2017, 8:41 PM.
Tags
None
Referenced Files
F168849503: D12561.id.diff
Sun, Aug 30, 10:56 AM
F168832646: D12561.diff
Sun, Aug 30, 9:02 AM
Unknown Object (File)
Sat, Aug 29, 11:29 AM
Unknown Object (File)
Fri, Aug 28, 6:57 PM
Unknown Object (File)
Wed, Aug 26, 7:06 PM
Unknown Object (File)
Wed, Aug 26, 6:37 PM
Unknown Object (File)
Wed, Aug 26, 4:32 PM
Unknown Object (File)
Wed, Aug 26, 4:20 PM
Subscribers

Details

Summary

When the EVENTHANDLER(9) subsystem was created, it was a documented feature that an eventhandler callback function could safely deregister itself. In r200652 that feature was inadvertantly broken by adding drain-wait logic to eventhandler_deregister(), so that it would be safe to unload a module upon return from deregistering its event handlers.

There are now 145 callers of EVENTHANDLER_DEREGISTER(), and it's likely many of them are depending on the drain-wait logic that has been in place for 8 years. So instead of creating a separate eventhandler_drain() and adding it to some or all of those 145 call sites, this creates a separate eventhandler_drain_nowait() function for the specific purpose of deregistering a callback from within the running callback.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I don't see anything horrible here.

This revision is now accepted and ready to land.Oct 1 2017, 9:58 PM
This revision was automatically updated to reflect the committed changes.