Aaron Stone wrote:
> The current fix is very minimal, and I believe it does the trick. But
> looking into it some more, I think we can make a slightly broader change
> that has the same effect but with fewer calls to fcntl...
agree.
> We should check to see if the listen sockets inherit blockin
The current fix is very minimal, and I believe it does the trick. But
looking into it some more, I think we can make a slightly broader change
that has the same effect but with fewer calls to fcntl...
On Fri, 2006-11-17 at 09:53 +0100, Paul J Stevens wrote:
> Aaron,
>
> looking at your patch; why
Aaron Stone wrote:
> I opened and then promptly resolved bug # 449 to document this issue and
> the fix that is now in SVN.
>
> I would very much like to see that each non-trivial* change in the 2.2.x
> series is identified with a bug number.
I agree.
--
Aaron,
looking at your patch; why do we need to restore the blocking flags on
the listenSocket? Isn't it enough to just force blocking on the client
socket?
Aaron Stone wrote:
> I opened and then promptly resolved bug # 449 to document this issue and
> the fix that is now in SVN.
>
> I would ve
I opened and then promptly resolved bug # 449 to document this issue and
the fix that is now in SVN.
I would very much like to see that each non-trivial* change in the 2.2.x
series is identified with a bug number.
(* where trivial means something like a change to the Debian packaging,
or a typo i
On Thu, 2006-11-16 at 23:31 +, Aaron Stone wrote:
> > What happens in 2.2.0 is somewhat similar to what is described above: a
> > child has done a O_NONBLOCK when another does F_GETFL. This way, the
> > client socket ends up being non-blocking - which is not what the calls
> > to fgets expect.
On Thu, Nov 16, 2006, Paul J Stevens <[EMAIL PROTECTED]> said:
> Aaron Stone wrote:
>> Conflicting issues:
>> http://cr.yp.to/unix/nonblock.html
>>
>> man 2 accept:
>> NOTES
>>There may not always be a connection waiting after a SIGIO is
>>delivered or select(2) or poll(2) ret
Aaron Stone wrote:
> Conflicting issues:
> http://cr.yp.to/unix/nonblock.html
>
> man 2 accept:
> NOTES
>There may not always be a connection waiting after a SIGIO is
>delivered or select(2) or poll(2) return a readability
>event because the connection might have been r
Conflicting issues:
http://cr.yp.to/unix/nonblock.html
man 2 accept:
NOTES
There may not always be a connection waiting after a SIGIO is
delivered or select(2) or poll(2) return a readability
event because the connection might have been removed by an
asynchronous n
Looks like I've nailed it already. Hang on.
Paul J Stevens wrote:
> Aaron,
>
> there's a serious problem in the select based setup.
>
> With the O_NONBLOCK flags, we run into problems with non-blocking client
> sockets, even though I thought I had fixed this.
>
> Without the whole fnctl dance,
10 matches
Mail list logo