[PATCH] tevent and threads - infrastructure improvements - version #2

[Simo Sorce]

On Mon, 2015-07-27 at 09:32 -0700, Jeremy Allison wrote:
> On Mon, Jul 27, 2015 at 08:54:24AM -0700, Jeremy Allison wrote:
> > On Mon, Jul 27, 2015 at 05:02:43AM -0400, Simo Sorce wrote:
> > 
> > > if we are unlucky it may cause flailing test failures on
> > > some architectures. Also if I read it right 'finished' is on the stack
> > > and you have a timeout that can make the thread terminate before the
> > > master writes to it, this could cause the test to write on freed/reused
> > > stack or segfault or similar causing also undebuggable testing failures.
> > 
> > See above - master never writes to it, only child
> > thread (who owns it for the lifetime) does.
> 
> Just to be completely clear, master thread neither
> reads nor writes to 'finished', only child thread
> which owns it completely.
> 
> All the master thread does is schedules thread_callback()
> to be run in child thread from within child thread
> event loop. That's why I really like this pattern,
> it makes it easy to avoid having to lock stuff
> as it doesn't facilitate sharing data across threads.

Yes I get that, which is why I like the architecture, but I think it is
a tad hard to use if you need to run a helper in a thread and get back
results. We need something like the thread_run thing I proposed, so
people do not have to play manually with thread_proxy_schedule and
instead can make a tevent call similar to the others they are used to,
with the understanding that the child callback is run completely in the
thread and that the memory passed to the callback will be moved to that
thread too (and then perhaps back).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York