evtimer_new "leak"

[Michael Herf]

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 ***@freehaven.net with
unsubscribe libevent-users in the body.

[B.R.]

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

Post by Michael Herf
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
***********************************************************************
unsubscribe libevent-users in the body.