On 8/22/06, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:> > Not to mention the name used causes (at least me) some confusion with BSD's> > kqueue implementation. Skimming over the patches it actually looks somewhat> > like kqueue with the more interesting features removed, like the ability to> > pass the filter changes simultaneously with polling.>> I do not understand, what do you mean?> It is obviously allowed to poll and change kevents at the same time.

Changing kevents are done with a separate system call from pollingafaics, thus every change requires a context switch. This in contrastto BSD's kqueue which allows user-space to pass the changes whenkevent (polling) is called.

It may also choose to update the filters immediately with the same call.

> > Maybe this is a topic that will singe my fur, but what is wrong with the> > kqueue API? Will I really have to implement support for yet another event> > API in my program.>> Why did I not implemented it like Solaris did?> Or FreeBSD did?> It was designed with features mention on AIO homepage in mind, but not> to be compatible with some other implementation.> And why should it be?

If it can be, why should it not be? At least, if you reinvent thewheel its advantages should be obvious.

Considering that kqueue is available on more popular OSes like darwinit would ease portability greatly if there was a shared event API.That is, unless you think there's something fundamentally wrong withtheir design.

The only thing missing in BSD's kevent is the min/max parameters, thevarious filters in kevent_get_events either have equivalent filters orcould be added as extensions. (I didn't look too carefully throughthem)

On the other hand, your API lacks the ability to pass changes whenpolling, as mentioned above. It would be preferable if the timeoutparameter was either timespec or timeval.