Trying to understand the idiom around tevent_req_defer_callback ...

Stefan Metzmacher metze at
Mon Nov 2 22:35:53 UTC 2015

Hi Richard,

>>> I came across this sequence in smbd_smb2_notify_reply:
>>>         tevent_req_defer_callback(req, state->smb2req->sconn->ev_ctx);
>>>         if (!NT_STATUS_IS_OK(state->status)) {
>>>                 tevent_req_nterror(req, state->status);
>>>                 return;
>>>         }
>>>         tevent_req_done(req);
>>> In looking at _tevent_req_notify_callback it seems the function of
>>> tevent_req_defer_callback is to ensure that the callback is not called
>>> until we get back to the creator of this request and have given it a
>>> chance set a callback.
>>> Do I have that correct or have I totally misunderstood?
>> The docs...
> Yeah, I saw that documentation in the code, but it is worthless for
> this case, it seems to me.
> The documentation talks explicitly about multiple events and shows a
> loop where tevent_req_done is being performed on multiple events, but
> it does not seem like there are multiple events in the case of
> smbd_smb2_notify_reply. Is the call to tevent_req_defer_callback
> unneeded in this case?

In some cases it might not be strictly required, but I think it's safer
to call it as:

- change_notify_reply() doesn't always return directly after calling

- change_notify_remove_request() is called after change_notify_reply().

- Also remove_pending_change_notify_requests_by_fid() also has a loop.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list