On Tue, Aug 07, 2007 at 06:56:23PM +0200, Emil Romanus wrote:
> > [...] CURLOPT_PROGRESSFUNCTION [...]
>
> I think it's not recommended simply because you would most likely need to
> perform mutex locking and other stuff on your own.

I don't see why this would be the cause... hm, maybe it gets called too
frequently, so it may cause performance issues? It would be nice to get
this clarified...
Anyway, you can also simply put the code into your CURLOPT_WRITEFUNCTION.

> > I have an application with GUI main-thread and worker thread with
> > libcurl multi-interface downloading and want to make progress bars in
> > GUI window for every active downloading.

You may get away without locking, actually: Your own code in the progress
function can write to a single "nr of bytes downloaded" integer, and the
GUI only reads that integer. On most multi-processor architectures,
"syncing" a word of data between processors will appear to be atomic, as
whole cache lines are synced and they are a multiple of the word size.
Thus, your GUI thread will never see a mixture of "old" and "updated" bytes
in the word. Of course, the GUI thread will have to poll for changes... :-/

By the way, if your GUI happens to be GTK+, I've written some glue code
called "glibcurl" which eliminates the need for a separate download thread,
and thus for locking; see <http://atterer.net/glibcurl/>.

Cheers,

  Richard

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