> If only one timer per request is needed it is better to store it in the
> module context. Yesterday announced JavaScript module does exactly like
> this.

Surely I will take a look at it!

> More to say, the timers mechanism is request agnostic. nginx doesn't track
> if the timer (wev) structure is already trashed, or even the entire request
> is freed. So you have to manage the lifetime of the timer manually.

Like I said, my request is not freed because I lock responding to the
client with http chunked response and buf->last_buf = 0. At least I
think my request would not be freed until I call ngx_finalize_request,
right?

> JS module does it with a cleanup handler wich fires just at a time of a
> request destruction. Yep, think of it as a destructor.
>
> In the clenup handler the module can check if the request has the module
> context, then just delete a timer with ngx_timer_del().

Using the context seems good, I will give it a try, sure.

> Even more to say. Developer needs to say to nginx that the request is
> referenced by a timer (there is no auto GC unfortunately). In the 0.8.*
> series of nginx it could be done by incrementing the r->main->count. And do
> not forget to decrement it when the work with the request is finished. You
> may think of it as a reference counting (like in Perl). nginx 0.8.* is about
> to become a stable branch, so no risks here.

I am using 0.7, so this reference counting is not an option yet.

Regards,
--
Rogério Schneider
http://stockrt.github.com

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel