[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <456B3A7C.20301@redhat.com>
Date: Mon, 27 Nov 2006 11:20:28 -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>
Subject: Re: [take25 1/6] kevent: Description.
Evgeniy Polyakov wrote:
> If kernel has put data asynchronously it will setup special flag, thus
> kevent_wait() will not sleep and will return, so thread will check new
> entries and process them.
This is not sufficient.
The userlevel code does not commit the events until they are processed.
So assume two threads at userlevel, one event is asynchronously
posted. The first thread picks it up, the second call kevent_wait.
With your scheme it will not be put to sleep and unnecessarily returns
to userlevel.
What I propose and what has been proven to work in many situations is to
have part of the kevent_wait syscall the information about "I am aware
of all events up to XX; wake me only if anything beyond that is added".
Please take a look at how futexes work, it's really the same concept.
And it's really also simpler for the implementation. Having such a flag
is much more complicated than adding a simple index comparison before
going to sleep.
--
➧ 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists