Adrian Chadd wrote:
> .. I read that as "the code is broken and needs to be fixed."
I think not so broken because there are solutions or workarounds off the
problems.
I think the last changes fix the problem (however I want to look more on
this to be sure there are not any other problems....).
> Ideally we wouldn't have this mess. I've never liked the close
> handlers in the first place; the code shouldn't be using fd's
> but should be using some opaque "connector" type which has
> a bunch of methods, including send/receive/timeout/etc;
I fully agree with you here. The operations should not be done directly
on file descriptors. But the subject of async calls project is different.
> really, how the heck are you calling HttpStateData::SendComplete()
> with a file descriptor thats invalid?
>
The problem was that when the HttpStateData::SendComplete scheduled the
descriptor was valid. But a comm_close on this file descriptor could
make it invalid before the HttpStateData::SendComplete really executed.
> The tunnel code could be fixed by doing something like:
>
> close_server()
> {
> server_fd = -1; /* We can't use it anymore */
> if (client_fd > -1)
> comm_close(client_fd);
> }
>
> close_client()
> {
> client_fd = -1; /* we can't use it anymore */
> if (server_fd > -1)
> comm_close(server_fd);
> }
I first saw the bug in tunnel.cc and I implement something like that you
are sugesting here. But then I found that the problem is not appeared
only in tunnel.cc code, but also in http.cc code and maybe in other
places ....
Received on Sun Jan 06 2008 - 04:52:47 MST
This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST