Threading libsmbclient - a proposal.

[Jeremy Allison]

On Sat, Apr 04, 2009 at 10:53:12AM -0700, Howard Chu wrote:
>
> Stepping back a bit, in the context of the mutex functions, there's 
> another consideration. Jeremy was talking about allocating an array of 
> global locks, which makes good sense. But if the caller hasn't 
> initialized the mutex methods, then that array will most likely be NULL, 
> and calling a dummy mutex function unconditionally will still mean 
> dereferencing a NULL pointer to give it the expected mutex.
>
> So for sanity's sake, this route is better...
>
> +#define        MUTEX_LOCK(x)   (_tdb_mutex_methods ?  
> _tdb_mutex_methods->tmm_lock(x) : 0 )
> +#define        MUTEX_UNLOCK(x) (_tdb_mutex_methods ?  
> _tdb_mutex_methods->tmm_unlock(x) : 0 )
> +#define        MUTEX_TRYLOCK(x)        (_tdb_mutex_methods ?  
> _tdb_mutex_methods->tmm_trylock(x) : 0 )

Yeah I saw your fixes. I had a long chat with tridge on
Friday about this and his preference is to add this
code to lib/replace rather than having each independent
subsystem have to have their own thread/mutex initializers,
as we're going to need to do this for more than just tdb.
I feel tdb might be a special case though as it's one of the
few independent libraries consumed externally.

His comment was that we should also have a single macro
that thread-requiring programs can call to define the
"normal" pthread version of the functions that will
be passed to initialize the libraries.

I'm thinking of something like :

SMB_PTHREAD_DEFINE_FNS(log_fn, var);

Which expands into definitions of all the functions
(using pthreads) we need to pass in to initialize,
and a definition and declaration of the struct to
pass (the logging function is optional and can be
NULL if not needed). var becomes the name of the
declared struct containing the vectors.

The main() function would then call

SMB_PTHREAD_INIT(var);

to actually cause the library to initialize the
thread functions, mutexes and TLS.

There's also functions for TLS we have to add, but I'll
look at that next week.

Jeremy.