[PATCH] tevent and threads - infrastructure improvements.

[Jeremy Allison]

On Thu, Jul 23, 2015 at 02:09:02PM -0700, Jeremy Allison wrote:
> On Thu, Jul 23, 2015 at 10:58:37PM +0200, Stefan (metze) Metzmacher wrote:
> > Am 23.07.2015 um 22:55 schrieb Jeremy Allison:
> > > On Thu, Jul 23, 2015 at 10:43:46AM +0200, Stefan (metze) Metzmacher wrote:
> > >>
> > >> True, maybe something like
> > >>
> > >> struct tevent_thread_proxy *tevent_thread_proxy_create(struct
> > >> tevent_context *main_ev);
> > > 
> > > That works - means more granular locks which is probably a
> > > good thing.
> > > 
> > >> void tevent_thread_proxy_schedule(struct tevent_thread_proxy *proxy,
> > >> 				  struct tevent_immediate **im,
> > >> 				  tevent_immediate_handler_t handler,
> > >> 				  void *private_data);
> > > 
> > > Don't think that works. The caller of tevent_thread_proxy_schedule()
> > > is the sending thread and should not get a handle back to the created
> > > struct tevent_immediate * object.
> > 
> > The caller would pass it and it got talloc_move'd.
> 
> Is there a reason for that, and not have tevent_thread_proxy_schedule()
> do it internally ?
> 
> It seems a clumsy extra step given that struct tevent_immediate *
> must always come back as NULL.
> 
> Is it to ensure im->create_location gets set to the
> correct point inside the caller ?

FYI. I now have a working implementation of this
API - passes valgrind memcheck and drd !

Hurrah for me :-).

Will post an updated patch once I've finished
updating the tutorial.

Cheers,

	Jeremy.