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

[Simo Sorce]

On Tue, 2015-07-28 at 08:48 -0700, Jeremy Allison wrote:
> On Tue, Jul 28, 2015 at 02:29:03AM -0400, Simo Sorce wrote:
> > On Mon, 2015-07-27 at 09:32 -0700, Jeremy Allison wrote:
> > > 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).
> 
> Well, thread_proxy_schedule *is* a tevent call similar
> to others they are used to. That's why metze suggested
> to do it that way :-).

I guess I am used to much to tevent_req stuff where I expect a callback
to be called when we get result. Maybe a wrapper should be done at that
level.

Simo.

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