On Thu, Jun 21, 2012 at 05:53:21PM -0400, jamal <h...@cyberus.ca> wrote:
> > I would be interested to learn under which conditions the availibility of
> > epoll_create1 and/or EPOLL_CLOEXEC is an actually measurable optimisation,
> > as opposed to being a correctness issue.
>
> I dont have any numbers.
> More that you pass the close on exec flag in libev with epoll_create1
> which i find useful.
I could understand missing epoll_create1, but it really doesn't matter
what epoll_create1 does, libev will flal back to epoll_create at runtime.
> With epoll_create(256) (where 256 used to mean num of descriptors) it
> essentially sys_epoll_create1(0) with kernels from the last 1-2 years
> which is missing the close on exec.
The kernel should return einval if it doesn't understand that flag
(but this is about libc, not kernel version, right?). Even if the
kernel silently ignores the flag, libev will just set it again as with
epoll_create.
> If that doesnt matter, why dont i just undefine EPOLL_CLOEXEC.
Well, you can break your stuff as you want, just make sure you don't blame
libev later when it breaks :)
--
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
