> 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 ...