On Sun, 6 May 2007, Ulrich Drepper wrote: > On 5/5/07, Davide Libenzi <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/