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?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html