2008/5/21 Daniel Stenberg <daniel_at_haxx.se>:
> We clearly lack a concept in the multi interface where we store sockets that
> are shared between easy handles, like for pipelining. So when one handle
> stops using a particular socket, the app gets told to remove it even if
> another handle is then immediately supposed to use it. If the order of the
> handles happens to be unlucky, the app will thus not wait for any socket
> actions on the socket currently used for a pipelined "session" ...
>
[...]
>
> I'll now start working on a redesign of some of these functions that will
> allow this kind of socket sharing. I think I may in fact get away with a
> system where I simply delay the removal of sockets until all handles have
> been checked.
>

I suspect your described problem might be the main source for the
problem I'm experiencing. Hopefully, your redesign will fix it, or at
least handle shared sockets better and thus ease the debugging and
fixing of subsequent problems. Thank you for the quick response and
help, I've been using libcurl for years now and regret I did not start
digging in the internals until now!

>
> There may be other problems as well, but before we fix this pretty serious
> flaw, there just won't be any functional http pipelining support with
> curl_multi_socket().
>

I'll continue studying the libcurl internals, and if my problem
remains after your fix is done, I will hopefully be able to help out
more.

Looking forward to hearing from you about any status updates regarding
the redesign.

--
 Emil