> Can you spot this with the latest release/git version? If so, can you try to
> write up a smallish stand-alone program that can repeat it?

I'll try to check this out if I find time.

I found in list archives that progress callback can be called from curl_easy_cleanup. This made me think if this is actually the right libcurl's approach or is my design correct.
 
> > It would be not safe, if we used CURLOPT_PROGRESSDATA pointing to an object
> > related to one transfer (destroyed after transfer has finished).
>
> You then assume that the CURLOPT_PROGRESSDATA pointer is equally wrong as the
> numbers, right? I'm not convinced that is a correct conclusion. Or have you
> observed that as well?
>

I'm thinking about design in which we have an object related to one transfer task. These objects can be enqueued, because only one transfer can be done at a time using particular easy handle (there can be more easy handle, but in this case we are talking about one ease handle and a queue of tasks that are waiting for this particular resource). When we start a transfer we pass a pointer to this task object to be provided in progress callback as a way to recognise which transfer this progress function call refers to. When transfer is finished (we received proper message from multi handle), that task is removed from system and its object destroyed.

So if mentioned bug still exists, in this design we can have a situation when CURLOPT_PROGRESSDATA pointer points to destroyed object.

Basically I'm trying to find the right design pattern for a situation when we have two resources: ZigBee and GPRS. For ZigBee I have one easy handle, because only one transfer can be allowed at a time. For GPRS I also have one easy handle for the same reason, but in the future maybe I will device to add some more "resources". So I need a way of mapping between ease handles and transfer tasks.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-10-28