On Tue, 9 Dec 2008, Igor Novoseltsev wrote:

> I implemented logic that doesn't remove socket from sockhash
> If the connection has other handles in pipes. In addition,
> At this moment I update the sockhash entry to point to the head handle.

Thanks for your patch and continued work on this.

There's one little detail that nudges me about this patch. Why are the
!isHandleAtHead() checks needed? Clearly if the socket is used for a pipeline,
meaning that at least one other handle is also using the same socket, then
surely the socket shouldn't be removed from the app no matter which of the
handles that are head at that given moment? I mean isn't it enough to spot
that it is part of a pipeline and thus used by another handle as well and then
it shouldn't be removed (yet)?

Also, to "repair" (setting the easy field of the entry struct to the head of
a pipe queue) the sockhash entry at that point seems a bit ineffective, if not
plain wrong, since then multi_socket() might already have ran on the wrong
SessionHandle.

But then I'm also getting a slight head ache when I consider the fact that
there are pipelines in both directions on the same socket so the "right"
SessionHandle also depends on what direction the "action" is at that point.

A minor nit is also that 'rename' is not a good name for a variable (it
shadows a global symbol), and if you build after having run configure
--enable-debug you'd see the warning for it!

> Do you want me to implement also the patch that "... If the extract
> SessionHandle is part of a pipe we can check if it is first in one of the
> pipes (recv and send). ... If it isn't first in the pipe for the checked
> direction, we can traverse the linked list with handles on that pipe and
> instead pick the one in the head and proceed using that instead...." ?

I think we need to consider this, yes. When we call libcurl to "act" on a
socket, we should make an effort to work with the easy handle that is at the
head of that pipeline (assuming the socket is used for pipelining of course).

-- 
  / daniel.haxx.se