Page MenuHomeFreeBSD

kqueue: slightly clarify the flow in knlist_cleardel()
ClosedPublic

Authored by kevans on Thu, Apr 2, 6:34 PM.
Tags
None
Referenced Files
F153059470: D56226.id175166.diff
Sat, Apr 18, 9:46 PM
Unknown Object (File)
Sat, Apr 18, 3:46 AM
Unknown Object (File)
Sat, Apr 18, 3:46 AM
Unknown Object (File)
Sat, Apr 18, 3:46 AM
Unknown Object (File)
Fri, Apr 17, 4:53 PM
Unknown Object (File)
Fri, Apr 17, 10:50 AM
Unknown Object (File)
Thu, Apr 16, 2:22 AM
Unknown Object (File)
Wed, Apr 15, 11:28 PM
Subscribers

Details

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 71920
Build 68803: arc lint + arc unit

Event Timeline

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

Could this be just for (;;) ?

sys/kern/kern_event.c
2794

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