[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4592DB7E.4090100@redhat.com>
Date: Wed, 27 Dec 2006 12:45:50 -0800
From: Ulrich Drepper <drepper@...hat.com>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
CC: David Miller <davem@...emloft.net>, Andrew Morton <akpm@...l.org>,
netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Chase Venters <chase.venters@...entec.com>,
Johann Borck <johann.borck@...sedata.com>,
linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>,
Alexander Viro <aviro@...hat.com>
Subject: Re: [take24 0/6] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote:
> Why do we want to inject _ready_ event, when it is possible to mark
> event as ready and wakeup thread parked in syscall?
Going back to this old one:
How do you want to mark an event ready if you don't want to introduce
yet another layer of data structures? The event notification happens
through entries in the ring buffer. Userlevel code should never add
anything to the ring buffer directly, this would mean huge
synchronization problems. Yes, one could add additional data structures
accompanying the ring buffer which can specify userlevel-generated
events. But this is a) clumsy and b) a pain to use when the same ring
buffer is used in multiple threads (you'd have to have another shared
memory segment).
It's much cleaner if the userlevel code can get the kernel to inject a
userlevel-generated event. This is the equivalent of userlevel code
generating a signal with kill().
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)
Powered by blists - more mailing lists