s4: Composite async callback on error conditions
Matthias Dieter Wallnöfer
mdw at samba.org
Sun Jan 16 02:54:02 MST 2011
Volker,
ah okay - I will let the fixing up to someone else since this seems very
tricky.
Cheers,
Matthias
Volker Lendecke wrote:
> On Sat, Jan 15, 2011 at 10:12:35PM +0100, Matthias Dieter Wallnöfer wrote:
>
>> Given the file "libcli/composite/composite.c":
>>
>>> _PUBLIC_ void composite_error(struct composite_context *ctx,
>>> NTSTATUS status)
>>> {
>>> /* you are allowed to pass NT_STATUS_OK to
>>> composite_error(), in which
>>> case it is equivalent to composite_done() */
>>> if (NT_STATUS_IS_OK(status)) {
>>> composite_done(ctx);
>>> return;
>>> }
>>> if (!ctx->used_wait&& !ctx->async.fn) {
>>> event_add_timed(ctx->event_ctx, ctx,
>>> timeval_zero(), composite_trigger, ctx);
>>> }
>>> ctx->status = status;
>>> ctx->state = COMPOSITE_STATE_ERROR;
>>> if (ctx->async.fn != NULL) {
>>> ctx->async.fn(ctx);
>>> }
>>> }
>>>
>> Regardless if an action succeeds (composite_done branch) or fails a
>> specified async callback is launched if it has been set. As far as I
>> can see this leads to problems: see http://build.samba.org/build.cgi/build/50b21d3db7ff575c3bdac41bedc8d77ab74680a9
>> (access in talloc destructor).
>> So my question: should we still be running async callbacks also on
>> failure conditions? Or can this particular problem be solved
>> differently?
>>
> While I don't know the current problem at hand, and I
> haven't really looked at the composite async programming
> variant for a while, let me comment from the tevent_req
> perspective (which I think is very similar to the composite
> one): Yes, you do want to run the async callbacks in the
> error case. The caller of the composite async process needs
> to be given a chance to detect the error by calling some
> form of _recv function. If you don't call the async
> function, the caller has no chance to take an appropriate
> action like a fallback to something different.
>
> With best regards,
>
> Volker
>
>
More information about the samba-technical
mailing list