[PATCH] tevent patches

Stefan (metze) Metzmacher metze at samba.org
Fri Feb 28 02:26:32 MST 2014

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
>> 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.
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.


More information about the samba-technical mailing list