Subject: Re: [RFC 1/4] kevent: core files.

From: Evgeniy Polyakov <[email-masked]>
Date: Fri, 28 Jul 2006 22:44:45 +0400

On Fri, Jul 28, 2006 at 11:33:16AM -0700, Zach Brown ([email-masked]) wrote:
> 
> > I completely agree that existing kevent interface is not the best, so
> > I'm opened for any suggestions.
> > Should kevent creation/removing/modification be separated too?
> 
> Yeah, I think so.

So, I'm going to create kevent_create/destroy/control and kevent_get_events()
Or any better names?

> >>> Hmm, it looks like I'm lost here...
> >> Yeah, it seems my description might not have sunk in :).  We're giving
> >> userspace a way to collect events without performing a system call.
> > 
> > And why do we want this?
> 
> So that event collection can be very efficient.
> 
> > How glibc is supposed to determine, that some events already fired and
> > such requests will return immediately, or for example how timer events
> > will be managed?
> 
> ...
> 
> That was what my previous mail was all about!

Some events are impossible to create in userspace (like timer
notification, which requires timer start and check when timer
completed).
Actually all events are part of the kernel, since glibc does not have
any knowledge about in-kernel state machines which are bound to
appropriate kevents, so each kevent takes at least two syscall (create
and get ready), and I do not see how, for exmple, glibc can avoid them
when user requested POLLIN or similar event for network dataflow?

According to syscall speed on Linux, last time I checked empty syscall 
took about 100ns on AMD Athlon 3500+.

> - z

-- 
	Evgeniy Polyakov