Page MenuHomeFreeBSD

kqueue: slightly clarify the flow in knlist_cleardel()
AcceptedPublic

Authored by kevans on Thu, Apr 2, 6:34 PM.
Tags
None
Referenced Files
F151257871: D56226.diff
Tue, Apr 7, 4:05 AM
Unknown Object (File)
Mon, Apr 6, 9:15 AM
Unknown Object (File)
Mon, Apr 6, 8:53 AM
Unknown Object (File)
Mon, Apr 6, 6:02 AM
Unknown Object (File)
Mon, Apr 6, 6:01 AM
Unknown Object (File)
Sat, Apr 4, 4:09 AM
Unknown Object (File)
Fri, Apr 3, 1:52 PM
Subscribers

Details

Reviewers
kib
markj
Summary

This is purely a cosmetic change to make it a little easier on the eyes,
rather than jumping back to the else branch up top. Re-flow it to use
another loop on the outside and just inline the re-lock before we repeat
after awaking from fluxwait.

The !killkn path should maybe issue a wakeup if there's a thread in
KQ_SLEEP so that userland can observe the EOF, but this isn't a
practical problem today: pretty much every case of knlist_clear is tied
to a file descriptor and called in the close(2) path. As a consequence,
potentially affected knotes are almost always destroyed before we even
get to knlist_clear().

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 71928
Build 68811: arc lint + arc unit

Event Timeline

kevans requested review of this revision.Thu, Apr 2, 6:34 PM
sys/kern/kern_event.c
2794–2818

Could this be just for (;;) ?

sys/kern/kern_event.c
2794–2818

I was mainly trying to avoid bothering with SLIST_FOREACH_SAFE on the last iteration if it's empty after we re-enter from fluxwait, but I don't feel that strongly about it- this isn't exactly a hot path.

Use an infinite loop instead, it's a little cleaner feeling.

This revision is now accepted and ready to land.Fri, Apr 3, 4:57 AM