Hi,

the truth is: the multi-interface isn't designed in way that it *would
be sanely thread-safe* or *could be made sanely thread-safe easily*. If
one puts locks for the multi-interface *outside* the interface instead
of locking *in* it, the multi-interface is ever-lastingly locked during
transfer, whereas I claim it should be able to potentially permanently
download something and at the same time take in new transfer requests.
Locks would have to be incorporated *within* the multi-interface,
*within* the data-structures used for transfers. You can't lock up the
multi-interface wrapping it. It's crazy because you perm-lock pretty
much everything you want to retrieve data from, because you lock
perm-traversals. Yet, there's only one shaky data-structure for handling
file transfers, and there's no possibility of differentiation
(data-structure-wise) between running downloads and finished downloads.
Having a look in the code of "multi.c", there's a funny remark at status
flag 'dl finished' (or other) which states something like: "we should
detach the node here and put it elsewhere"; it's a *list* (guarantor for
high performance), yes. So you can't just even adapt "multi.c" to fit
your needs, putting in some OMP code or other; no, you have to
practically rewrite "multi.c" to make your application thread-safe,
performant and usable on the one hand and in order to let it run in some
useful and sane concurrent mode for your application on the other hand.
You also can't just put locks in there since the authors have been
*wisely* mixing the logics of data structure traversal, data
manipulation and net transfers: a tight-fitting universal
built-in-and-around.

Short: If you wrap up the multi-interface for multi-threading purposes,
you will find yourself actually trying to (re)write what the code in
"multi.c" should have been.

Regards
Chr. Grade

Daniel Stenberg wrote:
> On Fri, 1 Sep 2006, Tom Jerry wrote:
>
>> So will it help if I lock the multi handle before accessing it on
>> both threads?
>
> lock? It will work if you have a mutex around your use of the multi
> handle, sure.
>
Received on 2006-09-05