Threading libsmbclient - a proposal.

[simo]

On Tue, 2009-04-07 at 16:56 -0700, Jeremy Allison wrote:
> On Tue, Apr 07, 2009 at 04:50:25PM -0700, Howard Chu wrote:
> > Jeremy Allison wrote:
> >> On Tue, Apr 07, 2009 at 04:15:26PM -0700, Howard Chu wrote:
> >>>
> >>> We often find the need for a trylock() op - fail immediately if the lock
> >>> is in use, instead of waiting.
> >>
> >> I thought about that one, but I don't see an immediate need
> >> for it in our code which will be mainly mutex locks around
> >> globals.
> >
> > In that case, your prototype is deceptive - you advertise read locks and 
> > write locks, which are typically held for the duration of a lengthy 
> > operation, not just taken and released quickly. If you're only expecting 
> > these locks to be used to essentially support atomic test-and-set, then 
> > the RDLOCK and WRLOCK usage makes no sense.
> 
> Well the goal is to allow the implementation to be
> upgraded at a later date to use pthread_rwlocks
> without changing the external interface.
> 
> Hmmm. Although in that case you're right, the
> interface doesn't work as we'd need to tell
> create_lock what kind of lock we'll need.
> 
> Do you think it's worth widening the interface
> now to include the reader/writer lock behaviour,
> or cut it down to just provide simple mutex's
> (which are all I think we'll need for the initial
> work anyway).
> 
> If we go fully threaded at a later date we may
> need to add rw locks then though...

If you think you can add other types of locks later on without changing
the public API I see no problem going step by step.
But keep in mind that the huge macro (or my proposed define), moves all
that code into the API.

If you later find you need to change that code you will have to break
compatibility with all applications that built against that interface.

I would really prefer not to.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>