> 1. File locking. It was said we need file locking to have several invoked
> curls all write to the same destination file. I have serious doubts
> around this. Not only do I suspect that people will still make mistakes
> when using a single output file, but we'll also get problems with systems
> that don't do proper locking (like various OSes or just systems running
> on NFS or similar).

On a similar note, we are investigating methods to allow several curl
handles (even used by different threads) to share a single cookie list.

The solution proposed by me is to create data type curl_cookie_list
(with no inherent mutex locking) and have curl call optional functions
whenever it wants to access the list:

curl_cookie_list clist;
/* build initial cookie list somehow */
curl_easy_setopt(CURL_COOKIELIST, &clist);
curl_easy_setopt(CURL_COOKIELIST_LOCK, lockfunction);
curl_easy_setopt(CURL_COOKIELIST_UNLOCK, unlockfunction);

curl would call lockfunction whenever it wants to read from the cookie list
(if lockfunction != NULL), und unlockfunction afterwards. The same happens
whenever curl wants to add a cookie to the list. By default, both function
pointers are NULL, and the clist is not thread-safe/shareable. If the
application wants a shareable list, it creates a mutex for this list (in
whatever thread-system it uses, for example pthreads) and passes functions
to (un)lock this mutex to curl - voila, a shareable clist.

Any comments to this?

Regards,
Ingo

-- 
ECCE TERRAM Internet Services GmbH          Ingo Wilken
Edewechter Landstr. 42                      delta_at_ecce-terram.de
26131 Oldenburg                             ++49 (0)441/500-12-0