glibc 2.9

Marc Lehmann schmorp at
Fri Jun 22 15:06:55 CEST 2012

On Fri, Jun 22, 2012 at 08:51:51AM -0400, Jamal Hadi Salim <jhs at> wrote:
> It does, but in the new kernels (which is what i use) that call is
> essentially being phased out. i.e. if i happen to compile with

I really don't believe that, that would be a first.

> EPOLL_CLOEXEC I get epoll_create1(EPOLL_CLOEXEC); otherwise i get 
> epoll_create(255) which translates to epoll_create1(0) when glibc
> call makes it to the kernel.

Glibc might emulate epoll_create with epoll_create1, but that doesn't mean
that the kernel phases it out, it also doesn't have anything to do with

If libev calls epoll_create, then, if glibc choses to emulate it with
epoll_create1, it will *just work*, while on older glibc's, it would just
call epoll_create.

> the libcs and the kernels;-> If i start maintaining personal OCD forks
> I am defeating the purpose. So it seems to me my best way forward is to
> just say "use glibc 2.9 and above".

The best way for you would be to use glibc 2.8 or newer - that will just
run on all newre libcs, until you hit a libc that has been deliberately
compiled without backwards compatibility. That would solve all technical
problems you have, unless you really have a race between ev_loop_new and
another thread that forks.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list