[Patches] Preparation for tevent impersonation (part1)

[Volker Lendecke]

On Thu, Jun 14, 2018 at 11:54:50PM +0200, David Disseldorp wrote:
> On Thu, 14 Jun 2018 20:37:37 +0200, Volker Lendecke wrote:
> 
> > > Talloc stackframe handling is broken in many of places, unfortunately.
> > > Continuing to use it for event based async code will only lead to more
> > > problems in future IMO.  
> > 
> > What do you propose instead?
> 
> In most async cases we already have a memory context for the request
> state, which makes a perfectly adequate parent for short-lived
> tallocations. It may mean passing mem_ctx arguments around a bit more,
> but is IMO far less error prone and easier to follow compared to random
> usage of the talloc_tos() global and subsequent garbage collection.

Manually passing down temporary contexts is just as error-prone: It's
too easy to accidentially pass down a long-term context where a
short-lived one is needed. For me talloc_tos() is a clear indication
that a short-lived one is requested. The guarantees for talloc_tos()
are that it lives as long as the current function runs and that it
will be cleaned up "quickly" after the function returned. Clear and
concise, at least to me.

I haven't followed precisely, but f4f3abfa0e18bb just committed might
be a good example of what can go wrong if you explicitly pass around
meant-to-be-short-lived contexts explicitly.

If talloc_tos() is no longer en vogue, we need a similarly concise
abstraction.

Even the "state" in async computations can be long-term. We have
_send/_recv functions that are really, really long-living. Look at
notifyd_send/recv. This "state" is just as long-living as smbd itself
is.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de