[PATCH] tevent and threads - infrastructure improvements.

[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);
> 
> void tevent_thread_proxy_schedule(struct tevent_thread_proxy *proxy,
> 				  struct tevent_immediate **im,
> 				  tevent_immediate_handler_t handler,
> 				  void *private_data);
> 
> tevent_thread_proxy_create() replaces your
> int tevent_threaded_context_register(struct tevent_context *ev);
> 
> TALLOC_FREE(proxy) replaces your
> int tevent_threaded_context_unregister(struct tevent_context *ev);
> 
> tevent_thread_proxy_schedule() replaces your
> tevent_threaded_async_call().
> 
> The thread creates a new struct tevent_immediate (or uses an existing one)
> and allocates all related private memory under it.
> 
> tevent_thread_proxy_schedule() talloc_moves im (including the private data)
> to the proxy. It notifies the main_ev and the trigger schedules the im
> on the main_ev. The handler can free im or reuse it later.
> 
> Using an explicit struct tevent_thread_proxy avoids using global variables
> and allows more than one proxy. This is important if some highlevel
> _send/recv function
> wants to use threads in the background. This will allow
> gensec_update_send/recv make use
> of this and call the gss_init_sec_context() in a thread.
> 
> As a helper we can also add a tevent_req_set_thread_proxy() a thread
> could then use:
> 
>    tevent_req_set_thread_proxy(req, state->thread_proxy);
>    tevent_req_done(req);
>    return;
> 
> I'd love to use something like this in Samba :-)

I know what that means in metze-speak, it means I want you to
do the work to re-write it :-) :-).

I'll take a look...

:-).