tdb API issues

[Stefan (metze) Metzmacher]

Howard Chu schrieb:
> Howard Chu wrote:
>> Howard Chu wrote:
>>>> It might also be possible to have a common virtual address space. To
>>>> do that we'd break up the tdb_context structure into per-thread and
>>>> per-process parts, and put the mapped pointers in the per-process
>>>> part. It would require some thought to make sure this is safe, but at
>>>> first glance I think its doable.
>>>
>>> OK, this sounds like a reasonable avenue to explore. If we also
>>> provide some
>>> callbacks for creating, locking/unlocking and freeing mutexes then we
>>> can
>>> explicitly make the relevant parts safe.
>>
>> I have a preliminary patch up on http://highlandsun.com/hyc/tdbdif.txt.
> 
> The majority of the patch is purely cosmetic; I added prefixes to all
> the tdb_context member names so that they can all be identified
> unambiguously.

Please remember we need a small atomic patches, which make sense on
their own and compile and work.

So such a rename only patch can go into master now, and the rest comes
when it's ready.

> (That also makes future global replaces a lot easier...)
> Then I split the tdb_context into a tdb_base_context which stores the
> main state, and the tdb_context which is "per-thread". A thread calls
> tdb_clone() to get its own working copy of a tdb_context, and all of the
> clones share the original's tdb_base_context. In the current setup, the
> original tdb_context must not be closed before any clones. (I guess it
> would be smarter to allocate the tdb_base_context independently, and
> refcount it.)
> 
> I'm not sure yet that I've split things between the base_context and the
> caller context correctly; this is still all a work in progress but I
> wanted to get some early feedback.

I thought about a similar problem but without real threads,
we open the tdb more than once from within one process.

I think in that case we should make sure that a transaction would only
be used from one caller.

The idea was to let tdb_transaction_start() return EWOULDBLOCK
if a transaction was already started on a different tdb_context
(currently it's tdbwrap_context) (if a transaction is started in
a different process we would also return EWOULDBLOCK).

Somehow the caller need to have way to register for a retry event,
but I have no specific idea for that. Maybe the caller needs pass some
callbacks so that tdb doesn't have a dependecy to an events system.

This would solve the problem where we serve multiple LDAP client within
one process, where each client has its own ldb_context, and we can only
allow a transaction for one client.

My first idea was to let tdb_transaction_start return a new tdb_context
with the transaction methods activated, while the existing tdb_context
gets readonly methods. That would mean only the caller who started the
transaction sees the intermediate transaction states and all other's
still see the pre transaction state of the tdb/ldb.

It would be nice we can somehow combine this two tasks.

I'm not sure if it would be possible, but I'd really like
if two threads can choose not to block on MUTEX_LOCK.

metze

> MUTEX_LOCK / MUTEX_UNLOCK macros are used where needed. If the caller
> didn't provide a set of mutex methods (via tdb_set_mutex()) then these
> macros will do nothing.
> 
>> the caller must call
>> tdb_set_mutex() and provide it a structure which contains a table of
>> mutex
>> function pointers. The tdb_set_mutex() function will then create whatever
>> locks it needs.
>>
>> The trick from here on out is identifying where all the locks need to
>> be inserted.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20090403/b7322f45/signature.bin