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.

s/EINTR/EAGAIN/

> 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 <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"