Re: [patch 14/22] pollfs: pollable futex

[Davide Libenzi <davidel@xmailserver.org>]

On Sun, 6 May 2007, Ulrich Drepper wrote:

> On 5/5/07, Davide Libenzi <davidel@xmailserver.org> wrote:
> > But we have our own *sane* version of WaitForMultipleObjects, and it's
> > called poll(2).
> 
> No, we don't.  Don't start all over again.  The interface of poll it
> to primitive.  See the kevent code, each record is, IIRC, 16 bytes in
> size to return more data.  For poll you only have bits.

Yes, event bits plus opaque token are enough for most of it. Then you use 
POSIX read/write to fetch/store the data. All the files (sockets, pipes, ...)
works this way. Signals you fetch a siginfo-like structure, through POSIX 
read. Timers, you fetch a counter, through POSIX read. AIO, you use the 
native AIO API (that I'd prefer, or you can choose to have a POSIX read 
too). All these through isolated POSIX read semantics.
Now let's see how it'd look with a monolitic kevent-like interface. You'll 
have a mosnter-union ala siginfo_t, with multiple nested structures, and 
every time you need to extend it, you'll go through pain. Come on, that's 
beyond ugly. With a file-like interface, each new addition comes to a 
seaparate isolated interface, with separate POSIX read/write ABI.
Do you realise that to justify your all new bulk interface, 
you had to pull out of the hat a Windows WaitForMultipleObjects?
Please drop the BS. I made you a full list of things that are readily and 
POSIX-friendly handled/signaled with file-like interfaces.
Any sockets, pipes, all devices, signals, timers, AIO, and I'm probably 
forgetting something.
You pulled "it's slow". False.
You pulled "it's memory expensive". It's not.
So far, I did not hear a single valid reason to go with a new, monolitic 
interface. WaitForMultipleObjects? Please ...



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/