Messages in this thread | | | Date | Mon, 9 Feb 2009 09:39:52 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch/rfc] eventfd semaphore-like behavior |
| |
On Mon, 9 Feb 2009, Michael Kerrisk wrote:
> On Thu, Feb 5, 2009 at 11:58 AM, Davide Libenzi <davidel@xmailserver.org> wrote: > > People started using eventfd in scnarios where before where using pipes. > > Many of them use eventfds in a semaphore-like way, like they were before > > with pipes. The problem with eventfd is that a read() on the fd returns > > and wipes the whole counter, making the use of it as semaphore a little > > bit more cumbersome. You can do a read() followed by a write() of > > COUNTER-1, but IMO it's pretty easy and cheap to make this work w/out > > extra steps. This patch introduces a new eventfd flag that tells eventfd > > to only dequeue 1 from the counter, allowing simple read/write to make it > > behave like a semaphore. > > Simple test here: > > > > http://www.xmailserver.org/eventfd-sem.c > > > > > > Signed-off-by: Davide Libenzi <davidel@xmailserver.org> > > Tested-by: Michael Kerrisk <mtk.manpages@gmail.com> > > Applied this patch against 2.6.29-rc3, and it works as I would expect. > > > A question or two.... This change is rather specific to a single use > case, so I wonder > > a) Are there use cases that require the ability to read an arbitrary > number of units off the eventfd -- i.e., read N units off the eventfd, > rather than just 1?
Not that I can think of.
> b) Is it desirable to be able to toggle the EFD_SEMAPHORE behavior on > and off for an eventfd?
This I'd say no. A synchronization entity in all decently sane sw design I've ever seen, remains the same in behaviour and it is never changed runtime to behave in different ways.
> It's difficult to see how these use cases could be accommodated in the > current API, but I just thought it worth raising the ideas.
Since read/write semantics cannot be changed (besides, like the semaphore change, for the amount of "data" dequeued), deeper changes to the interface will have to go via ioctl(). But I don't see any reason to go that way ATM.
- Davide
| |