Subject: Re: interrupting kevent()
To: Andrew Doran <firstname.lastname@example.org>
From: Antti Kantee <email@example.com>
Date: 10/24/2007 12:21:02
On Wed Oct 24 2007 at 02:36:32 +0100, Andrew Doran wrote:
> I haven't read kern_event.c without doing a runner yet, but the wakeup()
> should be done while holding the lock to avoid a sleep/wakeup race.
Which race? The "tickled" flag is set and checked for while holding
the lock. Sleep is not entered in the first place if it is set.
> > I considered writing to a socket, but couldn't figure out how to do it
> > without having to drain the signal byte from the socket therefore taking
> > two syscalls for signalling instead of one.
> So it's likely to happen often?
Yes, "always". Probably nothing to cry about, but why not get a little
gain for no cost?
> One other idea: provided that you know which thread is in kevent, you could
> mimic pthread cancellation but without the exit. That would not be portable
> though. Basically, test some kind of flag before and after the syscall, and
> in all cases do an _lwp_wakeup() on the kevent thread. (As an aside, it
> would probably be useful to have a pthread_getlwpid_np() call or similar.)
It's always the main thread.
But that feels fuzzy and detached from the kqueue concept. And besides
it would not work between processes sharing the fd table (I didn't test
my scheme to work in that case, but I don't see why it wouldn't).
Antti Kantee <firstname.lastname@example.org> Of course he runs NetBSD
"la qualité la plus indispensable du cuisinier est l'exactitude"