cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [SAD TRUTH] does curl_multi handle can be accessed from 2 threads?

From: Christian Grade <spam_at_tickles.de>
Date: Wed, 06 Sep 2006 15:12:13 +0200

You actually end up with two parallel bookkeeping mechanisms for the
transfer data at
two code abstraction levels: one in "multi.c", one in your own wrapper,
where one level
is redundant. This is undesirable per se. Things become even more
complicated if you
need to associate additional data with an hEasy. An 'easy node' should
have at least a
void* where you could pass your own struct to. The other way round
doesn't work for
me: handling nodes with an hEasy member outside the multi-interface;
this counteracts
the multi-interface purpose. On top of that, I think transfers should
rather be identified
by a hashed key (via url string) only.

I don't understand why you don't understand my complaints.
I'm pondering what I might be getting wrong here; also taking Richard
Atterer's follow-up
into account, which I admittedly don't understand in my context of
perception.

Regards
Chr. Grade

Daniel Stenberg wrote:
> On Tue, 5 Sep 2006, Christian Grade wrote:
>
>> 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*.
>
> The multi interface is thread-safe, but only from one thread at a
> time. I've explained this before.
>
>> 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,
>
> I don't understand what you're saying. If you call a function in a
> thread, then yes that function will be using that thread the whole time.
>
>> whereas I claim it should be able to potentially permanently download
>> something and at the same time take in new transfer requests.
>
> That's indeed possible with the multi interface. And it is being done
> by applications already.
>
>> Locks would have to be incorporated *within* the multi-interface,
>> *within* the data-structures used for transfers.
>
> If we would want to allow multiple threads to use the same multi
> handle, yes. But I haven't written it do allow that and I have no
> plans on doing so either. What would the point be?
>
>> 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.
>
> Sorry, I don't understand this point.
>
>> Yet, there's only one shaky data-structure for handling file transfers
>
> "one shaky data-structure" ?
>
>> and there's no possibility of differentiation (data-structure-wise)
>> between running downloads and finished downloads.
>
> What?
>
>> 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.
>
> I don't know what "funny remark" you're referring to, nor do I
> understand what you talk about.
>
>> So you can't just even adapt "multi.c" to fit your needs,
>
> Many people find that it fit their needs. Others think otherwise.
> You're free to use it or not. I certainly won't cry if you don't end
> up using it.
>
> Also, you could present your ideas and suggestion on how it would work
> instead. I haven't see any such.
>
>> 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.
>
> I strongly disagree. On the other hand I don't understand most of your
> complaints and you have not even tried to explain what you're trying
> to do.
>
>> 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.
>
> So why would you "wrap up the multi-interface" like that in the first
> place?
>
Received on 2006-09-06