Writing a timer event (how to execute an event from time to time)

Rogério Schneider stockrt at gmail.com
Tue May 25 15:47:24 MSD 2010

> 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,

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

Rogério Schneider

More information about the nginx-devel mailing list