On Tue, 20 May 2008, Daniel Stenberg wrote:

More analysis:

> It's clearly similar to the previous problems I fixed, in that when the
> state machine reaches a particular state (DONE) it stops monitoring the
> socket and sends REMOVE to the callback. But in this case I believe the
> _same_ socket is used by multiple easy handles so it shouldn't be removed
> until all handles are done using it.

That is certainly the problem I see.

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" ...

The problem is also that while we have internal *_getsock() functions that
return what sockets to wait for and how, for a single easy handle in all
states, we have no way for these functions to tell the caller which of the
sockets that are shared by other handles.

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.

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().

-- 
  / daniel.haxx.se