> > I didn't get response to my last update, quoted below.
> >
> > Did you see it?
> >
> > Do you think it is wrong?
>
> > Date: 2008-12-03 10:33
> > Sender: ketamin <https://sourceforge.net/users/ketamin/>
> > The patch works good!
> > Thank you very much!
> >
> > Although I have one doubt.
> > In ligth of your erlier remark regarding readchannel_inuse I think
we
> > should use
> >
> > if(Curl_removeHandleFromPipeline(data, conn->XXX_pipe) &&
> > conn->XXXchannel_inuse && conn->XXX_pipe->size > 0)
> > conn->XXXchannel_inuse = FALSE;
> >
> > instead of
> >
> > if(Curl_removeHandleFromPipeline(data, conn->XXX_pipe) &&
> > conn->XXXchannel_inuse)
> > conn->XXXchannel_inuse = FALSE;
>
> Yes I saw it and yes I think it's unnecessary.
>
> I tried to clarify the meaning of the XXXchannel_inuse fields in the
code
> just a few days ago:
>
> they're just flags that mean that the "channel" is in use and nobody
else can
> take it. So when we remove the handle at the head, the channel gets
available
> and the _inuse field can safely be set to FALSE and the next handle in
line
> would later become head and "take" the channel and set _inuse to TRUE
again.

The point is that we remove handle that is NOT in the head of the line!
This was exact the problem, if you remember. The handle that is not in
the head was not removed, causing crash later, when the handle is
accessed during manipulations on the list.

BTW, the fix I proposed is bad :)
We should not touch the XXXchannel_inuse at all, since we remove the
handle that is not in the head and the other handle that is in the head
probably deals uses the channel. If you agree with this we have to
remove the newly added function Curl_getoff_all_pipelines :(
Received on 2008-12-04