Subject: Re: interrupting kevent()
To: None <firstname.lastname@example.org>
From: Antti Kantee <email@example.com>
Date: 10/26/2007 12:32:15
On Thu Oct 25 2007 at 10:43:28 -0700, Bill Stouder-Studenmund wrote:
> Actually, signals do. Well, can. Check out the EVFILT_SIGNAL filter. It's
> MUCH saner than actual signal handlers. It event "works" for SIGBUS and
> SIGILL. The iSCSI target I worked on used it so we could log where the
> signal came from before panicing the app.
Yes, *can* but necessarily don't. And the problem: "Event notification
happens after normal signal delivery processing."
> 1) Generate an event. Bonus points for letting the ioctl pass in an
> intptr_t that gets sent down in the event. Strictly speaking, this means
> you'd have to enable a filter to catch it.
> 2) Something that doesn't overload an existing error code. (1) would do
> this. The main thing is that right now, if a kevent user gets EINTR, the
> right thing is to just spin around and try it again. With your change, the
> right thing to do might be to spin around and try again, or it might be to
> go do whatever the other thread wants us to do.
> 3) Something that the other BSDs might buy back on.
> I think the fact that we need a pipe to wake something up is kinda lame.
> poll() and select() had the same issue. So I would like to see some way to
> just send messages to a kevent user. My experince though is that we need
> more of a message than just, "Allo!"
Ok, I see what you want. However, I mysteriously lost a lot of my code
from Oct23rd (I still have the objects!) and I'm not going to bother to
rewrite it in the same fashion since it was *extremely* tedious work.
So I'll opt for another way creating threads earlier and I no longer
have a use for this facility. Sounds like a good suggestion, but someone
else feel free to implement it.
Antti Kantee <firstname.lastname@example.org> Of course he runs NetBSD
"la qualité la plus indispensable du cuisinier est l'exactitude"