I have changed the logic a bit and managed to both prove my point and
hide the problem. Basically, I'm not going through the cancel process
on a handle before I've received anything from the host: handles that
haven't received anything back yet but aren't needed any more are kept
in an "undead" state until work from the host arrives. This works well
(ie like with a libCurl compiled for Vista, I haven't seen anything
wrong yet).

Now, I'd expect to be able to remove a EasyHandle from a Multi even in
the dodgy case of having sent a request but not having received
anything back yet. I'm having the feeling that the way I'm handling
this, this is going to make things more complicated when handling
network loss and other fun little cases...

Is there a particular call I'm supposed to make when I want to cancel
a request? Or something else I'm missing?

Thanks
Jérôme

On 11/29/07, jérôme Muffat-Méridol <jmuffat_at_webphotomag.com> wrote:
> I'm currently thinking that the problem might be occuring when I'm
> cancelling a handle before the server has had a chance to reply.
>
> It looks like when the reply comes, libCurl thinks it is for a
> different handle.
>
> It's only an hypothesis, though: it doesn't look like the cancelled
> request and the one with wrong result have the same handle value (I
> expect there is some sort of resource reuse mechanism inside libcurl).
>
> Thanks
> Jérôme
>
Received on 2007-11-29