[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [take24 0/6] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote:
> It is exactly how previous ring buffer (in mapped area though) was
> implemented.

Not any of those I saw. The one I looked at always started again at
index 0 to fill the ring buffer. I'll wait for the next implementation.

>> That's something the application should be make a call about. It's not
>> always (or even mostly) the case that the ordering of the notification
>> is important. Furthermore, this would also require the kernel to
>> enforce an ordering. This is expensive on SMP machines. A locally
>> generated event (i.e., source and the thread reporting the event) can be
>> delivered faster than an event created on another CPU.
> How come? If signal was delivered earlier than data arrived, userspace
> should get signal before data - that is the rule. Ordering is maintained
> not for event insertion, but for marking them ready - it is atomic, so
> who first starts to mark even ready, that event will be read first from
> the ready queue.

This is as far as the kernel is concerned. Queue them in the order they

I'm talking about the userlevel side. *If* (and it needs to be verified
that this has an advantage) a CPU creates an event for, e.g., a read
event and then a number of threads could be notified about the event.
When the kernel has to wake up a thread it'll look whether any thread is
scheduled on the same CPU which generated the event. Then the thread,
upon waking up, can be told about the entry in the ring buffer which can
be accessed first best (due to caching). This entry needs not be the
first available in the ring buffer but that's a problem the userlevel
code has to worry about.

> Then I propose userspace notifications - each new thread can register
> 'wake me up when userspace event 1 is ready' and 'event 1' will be
> marked as ready by glibc when it removes the thread.

You don't want to have a channel like this. The userlevel code doesn't
know which threads are waiting in the kernel on the event queue. And it
seems to be much more complicated then simply have an kevent call which
tells the kernel "wake up N or 1 more threads since I cannot handle it".
Basically a futex_wake()-like call.

>> Of course it does. Just because you don't see a need for it for your
>> applications right now it doesn't mean it's not a valid use.
> Please explain why glibc AIO uses relatinve timeouts then :)

You are still completely focused on AIO. We are talking here about a
new generic event handling. It is not tied to AIO. We will add all
kinds of events, e.g., hopefully futex support and many others. And
even for AIO it's relevant.

As I said, relative timeouts are unable to cope with settimeofday calls
or ntp adjustments. AIO is certainly usable in situations where
timeouts are related to wall clock time.

> It has nothing with implementation - it is logic. Something starts and
> it has its maximum lifetime, but not something starts and should be
> stopped Jan 1, 2008.

It is an implementation detail. Look at the PI futex support. It has
timeouts which can be cut short (or increased) due to wall clock changes.

>> The opposite case is equally impossible to emulate: unblocking a signal
>> just for the duration of the syscall. These are all possible and used
>> cases.
> Add and remove appropriate kevent - it is as simple as call for one
> function.

No, it's not. The kevent stuff handles only the kevent handler (i.e.,
the replacement for calling the signal handler). It cannot set signal
masks. I am talking about signal masks here. And don't suggest "I can
add another kevent feature where I can register signal masks". This
would be ridiculous since it's not an event source. Just add the
parameter and every base is covered and, at least equally important, we
have symmetry between the event handling interfaces.

>> No, that's not what I mean. There is no need for the special
>> timer-related part of your patch. Instead the existing POSIX timer
>> syscalls should be modified to handle SIGEV_KEVENT notification. Again,
>> keep the interface as small as possible. Plus, the POSIX timer
>> interface is very flexible. You don't want to duplicate all that
>> functionality.
> Interface is already there with kevent_ctl(KEVENT_ADD), I just created
> additional entry, which describes timers enqueue/dequeue callbacks

New multiplexers cases are additional syscalls. This is unnecessary
code. Increased kernel interface and such. We have the POSIX timer
interfaces which are feature-rich and standardized *and* can be triviall
extended (at least from the userlevel interface POV) to use event
queues. If you don't want to do this, fine, I'll try to get it made.
But drop the timer part of your patches.

➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-20 21:35    [W:0.076 / U:2.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site