On Fri, Jan 04, 2008 at 03:47:33PM -0800, Jiang Xu wrote:
> My question is: if the work thread is in the middle of the callback that
> is called by curl_multi_perform(), what will happen if the control thread
> calls curl_multi_remove_handle() at the same time and they are all
> dealing with the same handle?

All sorts of interesting things will happen! But you probably won't like
the result. ;-)

Isn't the whole idea of the control thread *not* to make calls to libcurl
directly? Only the work thread should do this (and thus encapsulate the
fact that curl is used for the download), and the two should communicate
via message passing, monitors or similar.

If you have e.g. a case where the worker thread is busy, but the user has
decided to stop the download by clicking on a button, then the only option
is to delay destroying the curl_easy download a bit: The control thread
must send a message to the worker via a semaphore-protected message queue.
Sooner or later, libcurl will return from curl_multi_perform(), and at that
point the _worker_ should notice the new message and stop/destroy the
curl_easy download.

BTW, the worker can cause curl_multi_perform() to return earlier by
returning the value 0 from its CURLOPT_WRITEFUNCTION which indicates to
libcurl that something is wrong. In practice, you probably won't need to do
that, it usually doesn't matter if the download continues to run for
another 0.01 seconds...

HTH,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key: 888354F7
  | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC 8883 54F7
  ¯ '` ¯