Re: [squid-users] comm_select: kevent failure: (9) Bad file descriptor

Consider yourself beaten -- this has been bugging me for a while. :)

On 2007/03/26, at 5:31 PM, Adrian Chadd wrote:

> On Sun, Mar 18, 2007, Martin Solciansky wrote:
>> hello,
>>
>> we have been using squid-2.6.6 (with some security patches from
>> higher
>> versions and the kevent patch from .11) for some time now but few
>> weeks ago
>> we started getting:
>> 2007/03/17 08:25:12| comm_select: kevent failure: (9) Bad file
>> descriptor
>> 2007/03/17 08:25:12| Select loop Error. Retry 1
>
> I'm pretty sure I know why it is: Squid isn't removing the entries
> from
> the kqueue array when a filedescriptor is closed and if the
> filedescriptor
> isn't reused fast enough it'll end up throwing the above error.
>
> This error used to actually cause runtime leaks. I'm not sure if
> Henrik's
> recent work to mimic what libevent does has fixed it or not, but I
> do know
> the issue is still there.
>
> The real fix is to delay close() filedescriptors until its time to
> call
> kevent: on close(), modify the event in the array to be EV_DELETE,
> then
> close() all the filedescriptors. This is however very horrible and
> ugly.
> The fix I came up with for one of my private projects was to record
> the
> kevent array offset of the registered read/write events, if any, and
> rewrite them to be "null". Now, kqueue doesn't have any concept of an
> event slot thats to be ignored (unfortunately!) so you fake it with:
>
> * ident = 0 (fd = 0, for EV_READ and EV_WRITE filters)
> * filter = EV_READ or EV_WRITE, whatever's appropriate for what you're
> replacing
> * flags = EV_ADD | EV_DISABLE
>
> Kqueue doesn't mind if there's multiple filters added; it just
> overrides
> the currently registered one. The above is about as close to a NULL
> filter
> as you're going to get.
>
> I've done this in my test code to support loads much higher than Squid
> (~6k proxied req/sec (6k client sockets, 6k server sockets) with
> ~3000 to
> ~4000 concurrent connections. Its sane.)
>
> If someone wants to beat me to fixing then please, by all means. :)
>
>
>
>
> Adrian
>

--
Mark Nottingham       mnot@yahoo-inc.com