Re: [take12 0/3] kevent: Generic event handling mechanism.

[Jari Sundell]

On 8/22/06, Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote:
> Word "polling" really confuses me here, but now I understand you.
> Such approach actually has unresolved issues - consider for
> example a situation when all provided events are ready immediately - what
> should be returned (as far as I recall they are always added into kqueue in
> BSDs before started to be checked, so old events will be returned
> first)? And currently ready events can be read through mapped buffer
> without any syscall at all.
> And Linux syscall is much cheaper than BSD's one.
> Consider (especially apped buffer)  that issues, it really does not cost
> interface complexity.

There's no reason I can see that kqueue's kevent should not be able to
check an mmaped buffer as in your implementation, after having passed
any filter changes to the kernel.

I'm not sure if I read you correctly, but the situation where all
events are ready immediately is not a problem. Only the delta is
passed with the kevent call, so old events will still be first in the
queue. And as long as the user doesn't randomize the order of the
changelist and passes the changedlist with each kevent call, the
resulting order in which changes are received will be no different
from using individual system calls.

If there's some very specific reason the user needs to retain the
order in which events happen in the interval between adding it to the
changelist and calling kevent, he may decide to call kevent
immediately without asking for any events.

> First of all, there are completely different types.
> Design of the in-kernel part is very different too.

The question I'm asking is not whet ever kqueue can fit this
implementation, but rather if it is possible to make the
implementation fit kqueue. I can't really see any fundemental
differences, merely implementation details. Maybe I'm just unfamiliar
with the requirements.

> > BSD's kqueue:
> >
> > struct kevent {
> >  uintptr_t ident;        /* identifier for this event */
> >  short     filter;       /* filter for event */
> >  u_short   flags;        /* action flags for kqueue */
> >  u_int     fflags;       /* filter flag value */
> >  intptr_t  data;         /* filter data value */
> >  void      *udata;       /* opaque user data identifier */
> > };
>
>
> From your description there is a serious problem with arches which
> supports different width of the pointer. I do not have sources of ny BSD
> right now, but if it is really like you've described, it can not be used
> in Linux at all.

Are you referring to udata or data? I'll assume the latter as the
former is more of a restriction on user-space. intptr_t is required to
be safely convertible to a void*, so I don't see what the problem
would be.

> No way - timespec uses long.

I must have missed that discussion. Please enlighten me in what regard
using an opaque type with lower resolution is preferable to a type
defined in POSIX for this sort of purpose. Considering the extra code
I need to write to properly handle having just ms resolution, it
better be something fundamentally broken. ;)

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