> I agree about the principle, but I think we can make it even nicer:
>
> * We make Curl_expire() return a pointer to the newly added timeout struct.
>
> * We introduce a Curl_rmexpire() (perhaps a better name is needed) that more
>  explicitly removes the given timer, or if set to NULL, the entire list of
>  timers. (I think the most common use of 0 is in fact to quite accurately
>  remove all timers.)

This proposal is good. The original proposal might be simpler to code.

In this proposal, when would the newly allocated struct be freed?

In both proposals, you end up adding fields to the structs (e.g.
SessionHandle or hostthre.c:thread_data). In the first proposal, it's
an in-line timeout struct. In the proposal above, it's a pointer.

With the in-line proposal, there is no possibility of an out-of-memory
error, which could make error handling easier (e.g. the current tree
drops timeouts silently if malloc fails in multi_addtimeout).

With the in-line proposal, failing to unregister the timer before the
struct containing it is deleted leads to memory corruption. With the
pointer proposal, failing to delete the timer before the struct leads
to a memory leak. Neither is a desirable condition.

Either approach should work.

-Costa
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-08-17