Re: [take24 0/6] kevent: Generic event handling mechanism.

[Ulrich Drepper <drepper@redhat.com>]

Evgeniy Polyakov wrote:
> Event notification is not dropped - [...]

Since you said you added the new syscall I'll leave this alone.


> I repeate - timeout is needed to tell kernel the maximum possible
> timeframe syscall can live. When you will tell me why you want syscall
> to be interrupted when some absolute time is on the clock instead of
> having special event for that, then ok.

This goes together with...


> I think I know why you want absolute time there - because glibc converts
> most of the timeouts to absolute time since posix waiting
> pthread_cond_timedwait() works only with it.

I did not make the decision to use absolute timeouts/deadlines.  This is 
what is needed in many situations.  It's the more general way to specify 
delays.  These are real-world requirements which were taken into account 
when designing the interfaces.

For most cases I would agree that when doing AIO you need relative 
timeouts.  But the event handling is not about AIO alone.  It's all 
kinds of events and some/many are wall clock related.  And it is 
definitely necessary in some situations to be able to interrupt if the 
clock jumps ahead.  If a program deals with devices in the real world 
this be crucial.  The new event handling must be generic enough to 
accommodate all these uses and using struct timespec* plus eventually 
flags does not add any measurable overhead so there is no reason to not 
do it right.


> Kevent convert it to jiffies since it uses wait_event() and friends,
> jiffies do not carry information about clocks to be used.

Then this points to a place in the implementation which needs changing. 
  The interface cannot be restricted just because the implementation 
currently allow this to be implemented.


> 	/* Short-circuit ignored signals.  */
> 	if (sig_ignored(p, sig)) {
> 		ret = 1;
> 		goto out;
> 	}
>  
> almost the same happens when signal is delivered using kevent (special
> case) - pending mask is not updated.

Yes, and how do you set the signal mask atomically wrt to registering 
and unregistering signals with kevent and the syscall itself?  You 
cannot.  But this is exactly which is resolved by adding the signal mask 
parameter.

Programs which don't need the functionality simply pass a NULL pointer 
and the cost is once again not measurable.  But don't restrict the 
functionality just because you don't see a use for this in your small world.

Yes, we could (later again) add new syscalls.  But this is plain stupid. 
  I would love to never have the epoll_wait or select syscall and just 
have epoll_pwait and pselect since the functionality is a superset.  We 
have a larger kernel ABI.  Here we can stop making the same mistake again.

For the userlevel side we might even have separate intterfaces, one with 
one without signal mask parameter.  But that's userlevel, both functions 
would use the same syscall.


>> There are other scenarios like this.  Fact is, signal mask handling is 
>> necessary and it cannot be folded into the event handling, it's orthogonal.
> 
> You have too narrow look.
> Look broader - pselect() has signal mask to prevent race between async
> signal delivery and file descriptor readiness. With kevent both that
> events are delivered through the same queue, so there is no race, so
> kevent syscalls do not need that workaround for 20 years-old design,
> which can not handle different than fd events.

Your failure to understand to signal model leads to wrong conclusions. 
There are races, several of them, and you cannot do anything without 
signal mask parameters.  I've explained this before.


>> Avoiding these callbacks would help reducing the kernel interface, 
>> especially for this useless since inferior timer implementation.
> 
> You completely do not want to understand how kevent works and why they 
> are needed, if you would try to think that there are different than 
> yours opinions, then probably we could have some progress.

I think I know very well how they work meanwhile.


> Those callbacks are neededto support different types of objects, which
> can produce events, with the same interface.

Yes, but it is not necessary to expose all the different types in the 
userlevel APIs.  That's the issue.  Reduce the exposure of kernel 
functionality to userlevel APIs.

If you integrate the timer handling into the POSIX timer syscalls the 
callbacks in your timer patch might not need be there.  At least the 
enqueue callback, if I remember correctly.  All enqueue operations are 
initiated by timer_create calls which can call the function directly. 
Removing the callback from the list used by add_ctl will reduce the 
exposed interface.


>>> I can replace with -ENOSYS if you like.
>> It's necessary since we must be able to distinguish the errors.
> 
> And what if user requests bogus event type - is it invalid condition or
> normal, but not handled (thus enosys)?

It's ENOSYS.  Just like for system calls.  You cannot distinguish 
completely invalid values from values which are correct only on later 
kernels.  But: the first use is a bug while the later is not a bug and 
needed to write robust and well performing apps.  The former's problems 
therefore are unimportant.


> Well, then I claim that I do not know 'thing or two about interfaces of
> the runtime programs expect to use', but instead I write those programms
> and I know my needs. And POSIX interfaces are the last one I prefer to
> use.

Well, there it is.  You look out for yourself while I make sure that all 
the bases I can think of are covered.

Again, if you don't want to work on the generalization, fine.  That's 
your right.  Nobody will think bad of you for doing this.  But don't 
expect that a) I'll not try to change it and b) I'll not object to the 
changes being accepted as they are.


> What if it will not be called POSIX AIO, but instead some kind of 'true
> AIO' or 'real AIO' or maybe 'alternative AIO'? :)
> It is quite sure that POSIX AIO interfaces will unlikely to be applied
> there...

Programmers don't like specialized OS-specific interfaces.  AIO users 
who put up with libaio are rare.  The same will happen with any other 
approach.  The Samba use is symptomatic: they need portability even if 
this costs a minute percentage of performance compared to a highly 
specialized implementation.

There might be some aspects of POSIX AIO which could be implemented 
better on Linux.  But the important part in the name is the 'P'.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖