Subject: Re: interrupting kevent()
To: Antti Kantee <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 10/25/2007 10:43:28
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2007 at 01:44:05PM +0300, Antti Kantee wrote:
> On Wed Oct 24 2007 at 22:52:51 -0700, Bill Stouder-Studenmund wrote:
> > The canonical way I know to do this is to create a pipe and add a kevent
> > to listen to it. That way you get what you want w/o any kernel mods. Pl=
> > if you use an atomic write (everything in one write{,v}() call), then y=
> > can use the write to the pipe as a form of ITC (Inter-Thread
> > Communication) - not only do you wake the thread, but you carry the
> > message w/o needing locks on the sending side.
> Yes, but see other mails in the thread.  And no are locks needed now
> either.

You missed the point. I wasn't commenting that there is locking in your=20
patch that would be removed. There isn't. The comment was more about your=
app and what it has to do to actually send the message. Sure, you have to=
wake the main thread. But you also have to somehow tell it what to do. :-)=
A pipe and single writes does all of that in one step.

> > The concern/objection I have to what you do have is that it doesn't fol=
> > kevent methodology. I think your kevent should show up as an event. As =
> > stands, you only get an event if there is nothing else going on, and it=
> > shows up out-of-band with the events. A busy server could delay=20
> > conveying the "tickle" for a few system calls.
> Except it isn't a real event.  A signal doesn't show up as a real event.
> A timeout doesn't show up as a real event.  Why should this?

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=20
SIGILL. The iSCSI target I worked on used it so we could log where the=20
signal came from before panicing the app.

And I think the tickling really is an event. Another part of the app wants=
your main thread to do something, and both the existance of this desire=20
and details specific to it constitute an event.

> > So I'd like to politely ask you to go back to the drawing board. While =
> > think something other than a pipe could be cute, I think we should do=
> > something that will work in more cases than just your current one.
> Unfortunately with just vague handwaving I have no idea of what you
> want here.  Pending the kitchen_sink.h design, I'll use this method in
> my local tree and commit something general.

What I want is:

1) Generate an event. Bonus points for letting the ioctl pass in an=20
intptr_t that gets sent down in the event. Strictly speaking, this means=20
you'd have to enable a filter to catch it.

2) Something that doesn't overload an existing error code. (1) would do=20
this. The main thing is that right now, if a kevent user gets EINTR, the=20
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.=20
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=20
more of a message than just, "Allo!"

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)