[PATCH] tevent patches

[Amitay Isaacs]

On Fri, Feb 28, 2014 at 8:26 PM, Stefan (metze) Metzmacher
<metze at samba.org>wrote:

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

Hi Metze,

Yes, I was also wondering about the extra talloc cost when tracing is
enabled.

Here's another attempt after removing the extra talloc.  This one just adds
extra pointer to the event structures.

This is now a smaller change, but does not provide any generic mechanism
for stackable handlers.

Amitay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tevent.patches
Type: application/octet-stream
Size: 17134 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140228/95ff5538/attachment.obj>