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
Unknown Object (File)
Thu, Apr 16, 2:22 AM
Unknown Object (File)
Wed, Apr 15, 11:28 PM
Unknown Object (File)
Wed, Apr 15, 2:15 AM
Unknown Object (File)
Wed, Apr 15, 12:23 AM
Unknown Object (File)
Tue, Apr 14, 1:48 PM
Unknown Object (File)
Tue, Apr 14, 12:13 AM
Unknown Object (File)
Sat, Apr 11, 8:07 PM
Unknown Object (File)
Sat, Apr 11, 10:32 AM
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