Remove talloc from libwbclient

simo idra at
Sun Feb 7 08:10:45 MST 2010

On Sun, 2010-02-07 at 15:56 +0100, Volker Lendecke wrote:
> On Sun, Feb 07, 2010 at 09:44:50AM -0500, simo wrote:
> > Another possibility is to add an explicit thread safe call.
> > Something like talloc_ts_new(), and make sure it is used where
> > necessary.
> Sure. But we'd have to do a special talloc_ts_free() or add
> the corresponding check for a flag to talloc_free(). And
> ownership of a blob might change under talloc_steal().

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.

If we need to allow swapping memory ownership between threads we need to
consider carefully how we want to allow that.

> > I guess the only problem with making every NULL allocation a thread safe
> > one is to understand how many of them there are and how many would need
> > to be changed. But otherwise it looks a perfectly valid approach to me.
> 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.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list