[PATCHES] some new tevent features

[Stefan (metze) Metzmacher]

Hi Volker,

>>> >From 0a2bce1393e4c8e65b8f69c051c9a236319584b0 Mon Sep 17 00:00:00 2001
>>> From: Stefan Metzmacher <metze at samba.org>
>>> Date: Fri, 27 Sep 2013 03:41:29 +0200
>>> Subject: [PATCH 04/14] tevent: add/use tevent_req_destructor
>>>
>>> This makes sure we call tevent_req_received(req) on talloc_free()
>>> and cleanup things in a defined order.
>>
>> Are we 100% sure that no tevent_req user already does this?
> 
> I don't understand that question.

Ok, I got it, we have:

static int smbXcli_req_destructor(struct tevent_req *req)
static int fncall_destructor(struct tevent_req *req)
static int tldap_msg_destructor(struct tevent_req *req)

> In most cases the _recv() function should already call
> tevent_req_received().
> 
> But in some cases the _recv function doesn't or a request is
> abandoned by an implicit or explicit talloc_free(req).
> 
> Calling tevent_req_received() in the destructor (only if
> tevent_req_received()
> was not called before) means we free the children of 'req' in a defined
> order,
> req->internal.trigger and req->internal.timer before req->data.
> 
> This also means that we have req->internal.state = TEVENT_REQ_RECEIVED;
> while a possible destructor of req->data runs.
> 
> The main reason for this change is a patch that will follow later
> and introduces a cleanup callback that will be triggered by
> tevent_req_received(). This can be used to mark a connection as
> broken, if a caller does talloc_free(req) of a still pending request,
> which might only be partially send to a socket.

The new cleanup callback code I'm working on is able to replace the
implementation specific destructors.

As most of the reason to add the default tevent_req_destructor is the
cleanup callback
code, it's no problem if the implementation overwrites it with its own
destructor.
The important thing is that only the implemenation (the code that called
tevent_req_create()
and knowns the specific type of the tevent_req_data() result) overwrites
the destructor.

If a caller would do that it's really a bug and I'll see if we need to
make this more explicit
in the documentation. But currently I haven't found any bug like that in
master.

I think I'll defer the related patches and finish the cleanup callback
code with tests and resubmit.

In the meantime I'll push the changes without this.

metze