On Fri, Jun 22, 2012 at 08:51:51AM -0400, Jamal Hadi Salim <j...@mojatatu.com>
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
libev.
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_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
