[PATCH] tevent patches
amitay at gmail.com
Sun Mar 2 19:51:57 MST 2014
I have now two separate implementations.
1. Based on my initial patch set. This one just adds calls to trace
callbacks in various places. This adds a small cost when tracing is
disabled. However, this patchset is least intrusive and does not change
2. Second approach maintains zero additional cost when tracing is
disabled. This approach provides mechanisms for enabling/disabling tracing
for individual events. So it's much more fine grained control over
tracing. This one uses the wrapper functions to get/set callback
handler/data, so the implementation can be changed to call backend specific
functions when they are added.
These are two extremes. We probably want something in the middle. I guess
we can go ahead with first approach for now. When we decide to change the
ABI, use some of the elements from the second approach.
On Fri, Feb 28, 2014 at 11:44 PM, Stefan (metze) Metzmacher <metze at samba.org
> Am 28.02.2014 12:41, schrieb Volker Lendecke:
> > On Fri, Feb 28, 2014 at 10:26:32AM +0100, Stefan (metze) Metzmacher
> >> 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.
> > What about adding the tevent_trace_handler_data at the end
> > of the tevent structures in case they are needed and play
> > some offsetof magic in case the additional memory used is a
> > concern if the trace points are not needed?
> Yes, I think we can just add them into the structures, but that would be
> an incompatible change, which I'd like to avoid for now.
> Adding this information at tevent_add_fd() time would make things like
> turning tracing on and off at runtime, similar to 'smbcontrol debug',
> Maybe specifying the desired tracepoints after tevent_set_trace_callback()
> would be better.
More information about the samba-technical