[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha7-1034-g786447d

[Andrew Bartlett]

On Tue, 2009-04-14 at 08:00 +0200, Volker Lendecke wrote:
> On Tue, Apr 14, 2009 at 03:55:13PM +1000, Andrew Bartlett wrote:
> > > On Mon, Apr 13, 2009 at 11:05:16PM -0500, Andrew Bartlett wrote:
> > > > -	if (!push_ucs2_allocate(&buffer, src, &size)) {
> > > > +	if (!push_ucs2_talloc(NULL, &buffer, src, &size)) {
> > > 
> > > Any reason why you don't use talloc_tos() in your patches?
> > > Is there any flaw with talloc_stack.c that I should know
> > > about?
> > 
> > I did, in most of the places where it seemed reasonable (such as was
> > indicated by similar use in that context).  The rest I just did the most
> > simple replacement possible, to avoid introducing inadvertent errors.
> 
> So, what's the bug that you fear by s/NULL/talloc_tos()/?
> This *should* be idempotent but faster in smbd use.

Lack of thread safety at the bottom levels of library code.  Where other
parts of the code were already using talloc_tos() I've used it, as far
as I recall, but the implicit global variable semantics here spook me a
little.

Also perhaps I'm just not familiar with it - aside from not having to
have a mem_ctx argument around, what does this gain us?  Similarly a
talloc_free() will free all children, even those not cleaned up when a
child context was not talloc_free()ed.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090415/81624e40/attachment.bin