On Tue, Jun 26, 2012 at 08:26:01AM -0400, Jamal Hadi Salim
wrote:
> In the noise making that claim i lost the main point:
> The semantics have changed.
Not really.
> Now when i do epoll_create on new kernel, that param is ignored
> regardless of whether i have a new or old glibc.
Yes, but the
On Tue, 2012-06-26 at 00:01 +0200, Marc Lehmann wrote:
> > As you can see it translates to epoll_create1(0)
>
> As it should, no sign of it being phased out here.
Agreed - what i showed is backward compat support (typically this
is how i have seen things get phased out).
In the noise making tha
On Mon, Jun 25, 2012 at 09:12:02AM -0400, jamal wrote:
> Not sure about glibc emulating or what it means when you pass 255 to
> epoll_create being emulated, but here's what the kernel does when you
> call syscall epoll_create:
So the kernel fully supports epoll_create after all (epoll_create(255)
On Fri, 2012-06-22 at 15:06 +0200, Marc Lehmann wrote:
> Glibc might emulate epoll_create with epoll_create1, but that doesn't mean
> that the kernel phases it out,
Not sure about glibc emulating or what it means when you pass 255 to
epoll_create being emulated, but here's what the kernel does w
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 t
cacies and crazy changes in
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".
cheers,
jamal
___
li
On Thu, Jun 21, 2012 at 05:53:21PM -0400, jamal 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
On Wed, 2012-06-20 at 14:40 +0200, Marc Lehmann 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 th
On Wed, Jun 20, 2012 at 08:33:18AM -0400, jamal wrote:
> That would work to solve the problem - but i would miss out on the
> optimizations introduced by the new glibc (the defines in libev for
> EPOLL etc). To me the optimizations are more important.
I would be interested to learn under which co
On Wed, Jun 20, 2012 at 08:00:54AM -0400, jamal wrote:
> I cant recompile on every possible permutation of eglibc/uclibc/glibc
There are exactly two "permutations" of thes elibraries: uclibc and
glibc/eglibc. And yes, if you want to support uclibc, you have to
recompile. Just as you have to reco
On Wed, 2012-06-20 at 14:13 +0200, Zsbán Ambrus wrote:
> How about backwards compatibility? Could you compile the program only
> on a system with the older glibc version, and run it on a system with
> newer glibc?
That would work to solve the problem - but i would miss out on the
optimizations i
On Tue, Jun 19, 2012 at 8:33 PM, Marc Lehmann wrote:
> in general, glibc itself has no forward compatibility,
On Wed, Jun 20, 2012 at 2:00 PM, jamal wrote:
> I cant recompile on every possible permutation of eglibc/uclibc/glibc
> unfortunately - so that idea is dead on arrival.
> We may have to
On Tue, 2012-06-19 at 20:33 +0200, Marc Lehmann wrote:
> Since the only problem you mentioned is that you "don't like" the correct
> (and in fatc, only) solution to your problem, I would say your problem is
> not technological, but psychological in nature - nothing libev does can
> help you with
On Fri, Jun 15, 2012 at 06:13:18AM -0400, jamal wrote:
> glibc 2.9 and above added support for EPOLL_CLOEXEC + IN_CLOEXEC
>
> If i compile (and app-embed) libev on a system with glibc 2.9
> and try to run it on a system which is < glibc 2.9
> there is failure to load (since we
There's probably an easy way to do this. Note: This is not a libev
issue perse, rather a glibc compat issue.
glibc 2.9 and above added support for EPOLL_CLOEXEC + IN_CLOEXEC
If i compile (and app-embed) libev on a system with glibc 2.9
and try to run it on a system which is < glibc 2.9
15 matches
Mail list logo
