Threading libsmbclient - a proposal.

[Jeremy Allison]

On Fri, Apr 03, 2009 at 09:30:31AM -0400, Derrell Lipman wrote:
> 
> Thanks for pursuing this! I'm a bit uncertain, though, where you're going
> with it. If I understand you correctly, you're going to have libsmbclient
> create these locks that apply deep down in the bowels of the core code. If
> that's the case, it will mean that different threads could be blocked for a
> long period of time awaiting receipt of the lock.
> 
> There should be no thread safety issues remaining in libsmbclient itself (as
> long as one uses the lower-level interface where a context is passed to each
> function, and not the POSIX compatibility interface that uses a static
> context). Each thread allocates its own context, and libsmbclient should be
> thread-sfae. The state that needs locking is much deeper in the code, and
> locking it from within libsmbclient doesn't seem the correct place to do it.

Ok, so my comment "inside libsmbclient" was incorrect :-).

> Please elucidate a bit about how you anticipate this being used where you
> expect the lock calls to be made, and what, specifically, needs locking
> (i.e. where is the global state data currently). Based in ny current
> understanding of where you're going with this, I believe I have a different
> design that may be more efficient, but I'll first await your clarifications.

The places that need locking are deep inside the utility
code (name lookup, parameter reading etc.). So that's
where the call must go. The entry points for adding the
callback functions are smbc_XXX as I'm imagining the
libsmbclient people will be the first users.

The nice thing about this is that it has zero impact
on any of our other code (just some dummy function
calls in the code paths).

Jeremy.