On Thu, 22 May 2008, Emil Romanus wrote:

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

My current work-in-progress approach is to make things work like this:

When we deal with a pipeline, we have a sending queue and a receiving queue
(two linked lists of easy handles basically).

When we remove a handle from a list, and thus another one becames the first
one, the one that then can use the connection to send or to receive data, we
must make sure that this new handle at the start of the queue gets the proper
treatment.

That treatment includes getting a state change, and thus an updated set of
sockets and actions to wait for. (Currently this does not happen until the app
calls libcurl again, and since the attentino for the pipelined socket gets
removed from the application this will simply wait to happen until the timeout
is triggered for whatever reason).

This "proper treatment" is probably best done by a direct function call to
multi_socket() internally for that other easy handle, but I might also just
opt for lowering its timeout value to 0 and have a timeout callback asking for
an immediate "timeout call" from the app. The second approach might be
somewhat better in the sense that it follows the general existing concept and
it avoids becoming a recursive dilemma if for some reason the new handle too
gets remove from the queue and a third handles goes first, etc.

We'll see. I also get the feeling I might not have this fixed and ready in
time before the 7.18.2 release, but I will then jist do the release with this
bug fix pending for the subsequent release instead.

-- 
  / daniel.haxx.se