Re: epoll on squid

Hi David,

I've gotten to the bottom of this and now have a running version of
squid-epoll running (yippee!)

After upgrading glibc again and rebuilding epoll-lib and squid-epoll with
an added include (see below), it started working. The problem seems to
relate to the fact that the most recent glibc's published in Redhat Rawhide
which I am using, deliberately do not support the 'errno' symbol as a
built-in any more, and thus this needs to be explicitly defined via an
include in the epoll-lib/epoll.c source. [this has broken quite a few
apps..ugh]

 From Redhat Bugzilla, bug 80016:

>------- Additional Comment #1 From Jakub Jelinek on 2002-12-18 15:12 -------
>
>errno is not a symbol anything should use. All users of errno need to properly
>#include <errno.h> to get errno definition, seems Asbsoft is broken in this
>regard and needs to be fixed.
>
>------- Additional Comment #4 From Jakub Jelinek on 2002-12-18 15:12 -------
>
>It has been intentionally removed from glibc (well, with the exception of
>TLS enabled glibc build it is kept there for compatibility as runtime only
>symbol,
>but newly linked programs aren't allowed to reference it.
>errno in linux has been *__errno_location() for some 4 years or how long,
>this is the only way how to get the bugs fixed).
>With TLS enabled glibc which is going to rawhide RSN it is technically
>impossible to leave errno in (ld.so will automatically take care of
>GLIBC 2.0 compiled binaries and libs they use because __errno_location did not
>exist in there) and for more recent but buggy applications one can use
>LD_ASSUME_KERNEL=2.2.5 at runtime.

Fortunately squid does not have this problem with the newer glibc, it's
just an epoll-lib thing..

Anyway, upon inserting:

#include "errno.h"

in the epoll.c source file and rebuilding epoll-lib, the new libepoll.a
file allowed squid-epoll to link and run correctly. Perhaps my problems of
the other day were due to the fact that my old libepoll.a was built before
this include was explicitly needed. That's the price for living on the
bleeding edge I guess. I didn't need your workaround outlined below to get
things to work.

At present squid-3.0 is not stable for me so I can't hit epoll up hard, but
I did get to run epoll under light loads and it did compile clearnly and
work ok.

Reuben

At 05:25 PM 17/12/2002 -0500, David Nicklay wrote:

>I tried everything from scratch, by pulling the branch out of CVS and
>building it myself, but everything worked fine for me still even with
>the new linux kernel 2.5.52 and the newest tarball from squid-3.0-HEAD.
>
>On Tue, 2002-12-17 at 09:05, Reuben Farrelly wrote:
> > Thanks, that fixed the compile problem. Slowly getting there now :)
> > However upon starting, it spits out an error message:
>
>Okay, I can see what is happening in the following for you, but I don't
>understand why. It appears that epoll_ctl() is returning a -1, but then
>setting errno to 0 as if it succeeded which doesn't agree with its man
>page. That just doesn't make sense from examining the code in
>eventpoll.c in the kernel. Hrrrrmmm... *think* *think* *think*
>
>
> > 2002/12/18 00:51:21| Loaded Icons.
> > 2002/12/18 00:51:21| commSetSelect: cpoll_ctl(,EPOLL_CTL_MOD,,) failed on
> > fd=14!: (0) Success
>
>The epoll_ctl(,EPOLL_CTL_DEL,,) errors are probably related to the fact
>that it didn't call epoll_ctl(,EPOLL_CTL_ADD,,) previously, but instead
>failed through. Perhaps if we work around it for now by doing this:
>
>Change this:
>if (epoll_ctl(kdpfd, EPOLL_CTL_MOD, fd, &ev) < 0) {
> if(errno == ENOENT) {
>To this:
>if (epoll_ctl(kdpfd, EPOLL_CTL_MOD, fd, &ev) < 0) {
> if((errno == ENOENT) || (errno == 0)
>
>
>If that gets it working for you, let me know, and I will add it into the
>CVS branch.
>
>Also, what build environment and configure options are you using?
>
>
>--
>David Nicklay
>Location: CNN Center - SE0811A
>Office: 404-827-2698 Cell: 404-545-6218

-------------------------------------------------------------
Reuben Farrelly West Ryde, NSW 2114, Australia
Received on Fri Dec 20 2002 - 23:41:49 MST