My SSL is OpenSSL 0.9.8n. Looking at the epoll code, the logic seems that if read is pending, the squid needs something to trigger a read on the socket that is pending. But as there might not be incoming data to push kqueue/epoll into a read event for a long time. The code instead asking for a write event. The write event is almost sure an immediate trigger as the chance of write buffer full is low. However, once the write triggers and the read pending is on, a read callback is called instead of write. I will put in the epoll logic to kqueue. Will report its effect. Ming -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Wednesday, May 11, 2011 10:22 PM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: bug 1991/1939 and kqueue On 12/05/11 07:21, Ming Fu wrote: > Hi, > > I was looking into the fix for 1939 on Linux epoll. I am wondering if similarly apply the same modification to kqueue will do the same magic for 1991. On Linux epoll that fix seems to enable write monitoring whenever read_pending is present. I don't understand the logic, but if it works for Linux, would it work for FreeBSD as well? > > Regards, > Ming > Thank you for taking an interest in fixing bugs! Which version(s) or Squid and OpenSSL are you replicating it with? The logic goes that if there is read pending, then SSL might have something buffered needing to write. I suspect it may be a higher level problem with SSL omitting a write somewhere or a flags we omit to disable OpenSSl buffering. But if Henrik failed to find it, could be hard. Nothing beats experiments for finding things out. Try it and see. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.12 Beta testers wanted for 3.2.0.7 and 3.1.12.1
