Remove talloc from libwbclient

Volker Lendecke Volker.Lendecke at SerNet.DE
Sun Feb 7 08:22:15 MST 2010


On Sun, Feb 07, 2010 at 10:10:45AM -0500, simo wrote:
> Uhmm, I was thinking of setting a thread specific id and prevent any
> modification from any other thread, a talloc_steal() would work only if
> it is called by the same thread that created the memory context and only
> if the 2 memory trees you are touching are in the same thread.
> 
> Otherwise we need to make all talloc calls thread safe.

Yes, if they explicitly or implicitly touch
null/autofree_context.

My idea was that we mutex access to the null and autofree
contexts when they are to be touched and otherwise
completely leave talloc alone. Users of talloc are on their
own to coordinate the access to the talloc hierarchy of
everything one step below the NULL context. talloc.c takes
care to mutex access to the only shared variables it has:
null_context and autofree_context.

> > Right now there are quite a few, but as I said: Most of them
> > I inspected were easily replaceable by non-NULL ones. And
> > then, a mutex_lock/unlock should not hurt *that* much :-)
> 
> If you have to do that in every talloc call it becomes very expensive,
> especially in cases where you have many cores, and might be disastrously
> slow if you have NUMA architectures given how much we use talloc.

Sure, I would not want to do that in each talloc call, only
in the ones that affect null and autofree. The challenge
will be to figure out if we touch those two without mutex
calls.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100207/101cbe74/attachment.pgp>


More information about the samba-technical mailing list