I would even go further and suggest evtimer_new macro to be deleted. It brings absolutely no simplification to the underlying call to event_new since its signature is the same and all its parameters are sent to event_new.
evtimer, by semantic definition, only deals with timers, which is related to add/pending/del operations: it is thus strange to see it associated with event creation/deletion. Adding another duplicate named evtimer_free will add to the confusion and will probably lead to a whole set of function being duplicated (every time an event_* function does not exist in the evtimer_* format) My 2 cents, --- *B. R.* On Tue, Oct 7, 2014 at 1:50 AM, Michael Herf <[email protected]> wrote: > I wrote some code that was leaking on every call to evtimer_new -- I was > definitely calling evtimer_del afterwards (sometimes before the timer > fired). > > To fix the leak, I found out I actually needed to call event_free, > instead. Took me a while to go read the libevent code and figure this out. > > This seems kinda confusing API-wise, and if my understanding of it is > correct, adding an "evtimer_free" macro (also, evsignal_free, ...) or a > better explanation could save people some time. > > Michael > > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
