--EVF5PPMfhYS0aIcm
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=
us,
> > if you use an atomic write (everything in one write{,v}() call), then y=
ou
> > 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.
>=20
> 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=
=20
app and what it has to do to actually send the message. Sure, you have to=
=20
wake the main thread. But you also have to somehow tell it what to do. :-)=
=20
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=
low=20
> > kevent methodology. I think your kevent should show up as an event. As =
it=20
> > stands, you only get an event if there is nothing else going on, and it=
=20
> > shows up out-of-band with the events. A busy server could delay=20
> > conveying the "tickle" for a few system calls.
>=20
> 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=
=20
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=
=20
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 =
I=20
> > think something other than a pipe could be cute, I think we should do=
=20
> > something that will work in more cases than just your current one.
>=20
> 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=
=20
right thing to do might be to spin around and try again, or it might be to=
=20
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=
=20
just send messages to a kevent user. My experince though is that we need=20
more of a message than just, "Allo!"

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHINW/Wz+3JHUci9cRAuULAJ9io3okgqXdFJ0YITZXZSZdZSEClQCeOeG7
5vi+r+Xw6EiOk/VXDAyuoqk=
=hbUG
-----END PGP SIGNATURE-----

--EVF5PPMfhYS0aIcm--