Event-driven handler

[Dave Bailey]

I have similar needs, and would also like to have my module install a
callback that gets executed once per second (like the "trigger"
callback for lighttpd modules).

I think src/event/ngx_event.h has some things that may be useful
(ngx_add_event, etc).

-dave

On Tue, Feb 17, 2009 at 5:09 PM, Marcus Clyne <eugaia at gmail.com> wrote:
> Ryan Dahl <ry at ...> writes:
>
>>
>> > However, I'm not passing off the request via a socket -
>> > I'm running the code inside Nginx itself (it's written in C).
>> >
>> > I have the code running in a customized compiled Nginx binary, but
>> > currently the code is blocking (i.e. no other requests can be
>> > handled whilst my new code is being processed).  I'm looking to
>> > create a non-blocking version of my code, either through spawning
>> > off threads and handling each request in an isolated thread, or
>> > through some event-driven process.  I've not decided on that part of
>> > it yet, but I need to first get the code hooked into the event
>> > architecture of Nginx.
>>
>> It sounds like you should make it into its own process and
>> communicating with it via an upstream module. You're not gaining
>> anything by compiling something like that into Nginx.
>>
>>
>
> Maybe, but I'm not convinced that's correct. You are gaining, because you don't
> then have to deal with the overhead of opening and sending information over
> sockets.  I'm writing my code in C exactly because it's aimed towards very
> high-load servers, and I'd rather avoid any extra overhead if possible.
>
> The architecture is there for it to work just fine within Nginx, I just don't
> know how yet.  Also, there's a lot of code withing Nginx that I'd have to
> reproduce in order to run it in its own binary.
>
> If ultimately my code ends up destabilizing Nginx, then I would move it out into
> its own process, but I want to try to get it working without doing that first.
>
>
>