[PATCH] tevent patches

[Stefan (metze) Metzmacher]

Hi Amitay,

>> On Thu, Feb 27, 2014 at 09:03:30AM +0100, Stefan (metze) Metzmacher wrote:
>>> Hi Amitay,
>>>
>>>> Here are some improvements to tevent tracing functionality.  This was
>>>> especially useful for debugging CTDB and finding out what events are
>> being
>>>> triggered often.
>>>>
>>>> The patches are also available in my tree:
>>>
>>> We can't make trace point an compile time optional feature,
>>> smbd relies on this feature.
>>>
>>> Can you add a TEVENT_HAS_HANDLER_TRACE_POINTS define similar to
>>> TEVENT_HAS_LOOP_ONCE_TRACE_POINTS?
>>
>> Just brainstorming....
>>
>> Would it be possible to make these tracepoints if not used
>> 0-cost when a handler is executed? If a caller wants to have
>> trace points, can we wrap the handlers in another function
>> at tevent_add_fd time & friends?
>>
> 
> Here's second attempt at tracing patches. This one implements 0-cost
> handler when trace points are not used.
> Also added a define that can be used for configuration checks.

The problem I have with this is that this costs much more than
the first patchset for the most performance critical users
smbd and ctdbd. A additional talloc() call per event registration
costs a lot more than a function call to a noop function.

Also this add a memory leak in tevent_schedule_immediate().

So I'd prefer to just have my issues on the first attempt fixed.
Additionally we could think about something like
tevent_active_trace_point() to activate just the tracepoints
the implementation is interested in, while all of them are
activated by default.

However the struct tevent_trace_handler_data inspired me how to
possibly solve some problems in my attempt to implement
in my master3-impersonate branch.
https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=625286f6cf915f8f10a472ae9c066aee648d2086
This is also needed for our new dcerpc infrastructure, I'll work on that
in the next weeks.

Once we have a generic infrastructure to register wrapper handlers,
which doesn't require talloc and which are to some extent stackable,
we can think about changing the internal implementation.
But I fear this will require incompatible ABI changes.

metze