login
Login
/
Register
Search
Header Space
Forums
News
Jobs
Blogs
Features
Man Pages
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
February
»
26
Re: epoll design problems with common fork/exec patterns
view
thread
Score:
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From:
Davide Libenzi <davidel@...>
To: Michael Kerrisk <mtk.manpages@...>
Cc: David Schwartz <davids@...>, <dada1@...>, Chris "?" Heath <chris@...>, Linux-Kernel@Vger. Kernel. Org <linux-kernel@...>, <linux-man@...>
Subject:
Re: epoll design problems with common fork/exec patterns
Date: Tuesday, February 26, 2008 - 2:51 pm
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
quoted text
> Davide Libenzi wrote: > > On Sun, 28 Oct 2007, David Schwartz wrote: > > > >> Eric Dumazet wrote: > >> > >>> Events are not necessarly reported "by descriptors". epoll uses an opaque > >>> field provided by the user. > >>> > >>> It's up to the user to properly chose a tag that will makes sense > >>> if the user > >>> app is playing dup()/close() games for example. > >> Great. So the only issue then is that the documentation is confusing. It > >> frequently uses the term "fd" where it means file. For example, it says: > >> > >> Q1 What happens if you add the same fd to an > >> epoll_set > >> twice? > >> > >> A1 You will probably get EEXIST. However, it is > >> possible > >> that two threads may add the same fd twice. This is > >> a > >> harmless condition. > >> > >> This gives no reason to think there's anything wrong with adding the same > >> file twice so long as you do so through different descriptors. (One can > >> imagine an application that does this to segregate read and write operations > >> to avoid a race where the descriptor is closed from under a writer due to > >> handling a fatal read error.) Obviously, that won't work. > > > > I agree, that is confusing. However, you can safely add two different file > > descriptors pointing to the same file*, with different event masks, and > > that will work as expected. > > So can I summarize what I understand: > > a) Adding the same file descriptor twice to an epoll set will cause an > error (EEXIST).
Yes.
quoted text
> b) In a separate message to linux-man, Chris Heath says that two threads > *can't* add the same fd twice to an epoll set, despite what the existing > man page text says. I haven't tested that, but it sounds to me as though > it is likely to be true. Can you comment please Davide?
Yes, you can't add the same fd twice. Think about a DB where "file*,fd" is the key.
quoted text
> c) It is possible to add duplicated file descriptors referring to the same > underlying open file description ("file *"). As you note, this can be a > useful filtering technique, if the two file descriptors specify different > masks. > > Assuming that is all correct, for man-pages-2.79, I've reworked the text > for Q1/A1 as follows: > > Q1 What happens if you add the same file descriptor > to an epoll set twice? > > A1 You will probably get EEXIST. However, it is pos- > sible to add a duplicate (dup(2), dup2(2), > fcntl(2) F_DUPFD, fork(2)) descriptor to the same > epoll set. This can be a useful technique for > filtering events, if the duplicate file descrip- > tors are registered with different events masks. > > Seem okay Davide?
Looks sane to me. - Davide --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
epoll design problems with common fork/exec patterns
, Marc Lehmann
, (Sat Oct 27, 2:22 am)
Re: epoll design problems with common fork/exec patterns
, Eric Dumazet
, (Sat Oct 27, 4:23 am)
Re: epoll design problems with common fork/exec patterns
, Marc Lehmann
, (Sat Oct 27, 4:51 am)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Sat Oct 27, 12:59 pm)
RE: epoll design problems with common fork/exec patterns
, David Schwartz
, (Sun Oct 28, 12:47 am)
RE: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Sun Oct 28, 2:48 pm)
Re: epoll design problems with common fork/exec patterns
, Eric Dumazet
, (Sun Oct 28, 5:33 am)
RE: epoll design problems with common fork/exec patterns
, David Schwartz
, (Sun Oct 28, 5:04 pm)
RE: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Mon Oct 29, 2:55 pm)
Re: epoll design problems with common fork/exec patterns
, Michael Kerrisk
, (Tue Feb 26, 11:13 am)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Tue Feb 26, 2:51 pm)
Re: epoll design problems with common fork/exec patterns
, Chris
, (Tue Feb 26, 9:30 pm)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Wed Feb 27, 3:35 pm)
Re: epoll design problems with common fork/exec patterns
, Michael Kerrisk
, (Thu Feb 28, 9:12 am)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Thu Feb 28, 3:23 pm)
Re: epoll design problems with common fork/exec patterns
, Michael Kerrisk
, (Fri Feb 29, 11:46 am)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Fri Feb 29, 3:19 pm)
Re: epoll design problems with common fork/exec patterns
, Michael Kerrisk
, (Fri Feb 29, 3:54 pm)
Re: epoll design problems with common fork/exec patterns
, Michael Kerrisk
, (Thu Feb 28, 9:23 am)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Thu Feb 28, 3:34 pm)
Re: epoll design problems with common fork/exec patterns
, Willy Tarreau
, (Sat Oct 27, 1:38 pm)
Re: epoll design problems with common fork/exec patterns
, Mark Lord
, (Mon Oct 29, 6:36 pm)
Re: epoll design problems with common fork/exec patterns
, Davide Libenzi
, (Sat Oct 27, 2:01 pm)
Re: epoll design problems with common fork/exec patterns
, Eric Dumazet
, (Sat Oct 27, 5:22 am)
Re: epoll design problems with common fork/exec patterns
, Marc Lehmann
, (Sat Oct 27, 5:34 am)
Re: epoll design problems with common fork/exec patterns
, Eric Dumazet
, (Sat Oct 27, 6:23 am)
Re: epoll design problems with common fork/exec patterns
, Marc Lehmann
, (Sat Oct 27, 6:46 am)
Navigation
Create content
Mailing list archives
Recent posts
Mail archive search
Enter your search terms.
all mailing lists
alsa-devel
dragonflybsd-bugs
dragonflybsd-commit
dragonflybsd-docs
dragonflybsd-kernel
dragonflybsd-submit
dragonflybsd-user
freebsd-announce
freebsd-bugs
freebsd-chat
freebsd-cluster
freebsd-current
freebsd-drivers
freebsd-embeded
freebsd-fs
freebsd-hackers
freebsd-hardware
freebsd-mobile
freebsd-net
freebsd-performance
freebsd-pf
freebsd-security
freebsd-security-notifications
freebsd-threads
git
git-commits-head
linux-activists
linux-arm
linux-ath5k-devel
linux-btrfs
linux-c-programming
linux-driver-devel
linux-ext4
linux-fsdevel
linux-ia64
linux-input
linux-kernel
linux-kernel-janitors
linux-kernel-mentors
linux-kernel-newbies
linux-kvm
linux-net
linux-netdev
linux-newbie
linux-nfs
linux-raid
linux-scsi
linux-security-module
linux-sparse
linux-usb
linux-usb-devel
madwifi-devel
netbsd-announce
netbsd-tech-kern
open-graphics
open-graphics-announce-kt
openbsd-announce
openbsd-bugs
openbsd-ipv6
openbsd-misc
openbsd-security-announce
openbsd-smp
openbsd-source-changes
openbsd-tech
openfabrics-general
openmoko-community
openmoko-devel
openmoko-kernel
reiserfs-devel
tux3
ucarp
Optionally limit your search to a specific mailing list.
advanced
Popular discussions
linux-kernel
:
Peter Zijlstra
Re: Quad core CPUs loaded at only 50% when running a CPU and mmap intensive multi-...
Satyam Sharma
[-mm patchset] War on warnings
Izik Eidus
[PATCH 0/4] ksm - dynamic page sharing driver for linux
Renato S. Yamane
Error -71 on device descriptor read/all
git
:
Martin Langhoff
Handling large files with GIT
Wincent Colaiuta
Rebase/cherry-picking idea
Linus Torvalds
People unaware of the importance of "git gc"?
Joe Fiorini
Undo git-rm without commit?
openbsd-misc
:
Christian Weisgerber
Re: libiconv problem
Peter
OpenBSD as Virtualbox guest
Brandon Lee
DELL PERC 5iR slow performance
Martin Toft
Trying to compile cwm on Linux
linux-netdev
:
Alexey Dobriyan
[PATCH 01/53] xfrm: initialise xfrm_policy_gc_work statically
Arjan van de Ven
Printing the driver name as part of the netdev watchdog message
Dushan Tcholich
Re: ksoftirqd high cpu load on kernels 2.6.24 to 2.6.27-rc1-mm1
Inaky Perez-Gonzalez
[PATCH 03/39] wimax: constants and definitions to interact with user space
Latest forum posts
spam
11 minutes ago
KernelTrap Suggestions and Feedback
sis190/191 gigabit ethernet driver
1 hour ago
Linux general
read /dev/mem not working in 2.6
1 day ago
Linux general
Fedora with Windows vista : windows explorer restarts
1 day ago
Windows
Intel Graphics Drivers (IEGD 9.0.2) - help in patching for kernels > 2.6.24
1 day ago
Linux kernel
Porting from Windows to Linux
1 day ago
Linux general
Serial Driver Implementation Help
2 days ago
Linux kernel
aacraid bad
2 days ago
Linux general
Tools: GCC 3.4.6, Final GCC 3 Release
3 days ago
Applications and Utilities
GNU/Hurd is so awful
4 days ago
GNU/Hurd
Show all forums...
Recent Tags
more tags
Colocation donated by:
Who's online
There are currently
1 user
and
848 guests
online.
Online users
bartman
Syndicate
speck-geostationary