On Mon, 14 Jan 2002, Dirk Manske wrote:

> > Why should libcurl initialize the mutexes?

> Because we could add more mutexes to the libcurl internal without the
> needing to touch a (multithreaded) libcurl application. Maybe only 2
> mutexes are needed, maybe libcurl was someday 10 mutexes. If all theses
> mutexes must be initialize from the application it is not very nice.

Indeed a reasonable explanation. I didn't think of that.

But... it also depends on what the interface will look like that specifies
the sharing. If we have options that tell curl which pools to share, then
there won't appear any new ones out of the sky. I'm not entirely sure we
would like libcurl to start sharing new pools for old programs (this needs
very careful thinking first).

And just because libcurl invents another pool there would be a possibility to
have a mutex for, it isn't at all certain that the application would want
that or even that it would use that feature as it wasn't aware of it when the
program was written...

If I would write an application to deal with any possibly "new" mutexes, I'd
have a switch() on the mutex id and I'd have cases for all currently known
mutexes. The first time a mutex lock is requested, I'd create it. Then no
mutexes would ever be created in vain. Also, if there's a mutex request that
we have no specific case for, it'll fall into the default action that would
either use one single "mutex for all unknowns" or it would create one for the
particular id passed in right then.

Comments?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/