On Wed, Mar 09, 2011 at 03:23:09PM +0530, Joachim Breitner wrote:
> Am Mittwoch, den 09.03.2011, 10:22 +0100 schrieb Julien Cristau:
> > epoll_create1 was added in 2.6.27, afaict. If that's what haskell is
> > using, then it's not unexpected to have it fail on 2.6.26.
>
> #if defined(HAVE_EPOLL_CREATE1)
> c_epoll_create1 (#const EPOLL_CLOEXEC)
> #else
> c_epoll_create 256 -- argument is ignored
> setCloseOnExec fd
> #endif
>
> So what is the conclusion? Do we need to disable the use of
> epoll_create1 completely?
It gets you nothing unless there's a possibility another thread might fork
between epoll_create() and fcntl(FD_CLOEXEC).
> Or is it actually so that the libc should map uses of epoll_create1 to
> epoll_create? Or do we need to introduce run-time checks as to whether
> epoll_create1 is available?
There's no way around run-time checks if you want to be safe from this race,
yeah. It can be done either in libc or in your code; the former means less
code duplication but hurts badly any backporting.
Meow?
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309100921.ga11...@angband.pl
