Re: WSAPI vs. events

[Alexander Gladysh <agladysh@...>]

On Thu, Apr 14, 2011 at 05:44, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
> On Wednesday 13, Alexander Gladysh wrote:

> He is talking about having the WSAPI code block on more then one socket (the
> fastcgi Unix domain socket(UDS) and your own command socket).  In your case
> each WSAPI fork would have it's own unique UDS/pipe fd to receive your command
> messages from.  But it looks like the WSAPI interface will not allow you to
> block on both the fastcgi socket and your command socket.

>> Please explain, how can I react on different socket, when WSAPI is
>> blocking either on FCGI_Accept() or on fread() from FCGI stdin?

> Basically you can't.  At least without changing the fastcgi [1] library to use
> select() or some other event loop internally to allow you to have your WSAPI
> process wait for either a new HTTP request or a message from your command
> socket.

Exactly my point.

> One option would be to port your WSAPI handler to use the async. HTTP
> interface from my lua-handlers [2] project.  See the example HTTP server [3].
> With lua-handlers you can have your HTTP request handler wait for new requests
> and wait of a message from a command socket at the same time.  lua-handlers
> uses lua-ev for the event loop and lua-http-parser for parsing HTTP requests.

Thanks, but I think that if I will have to abandon WSAPI, I will
reinvent the wheel, and write my own lua-ev+lua-http-parser HTTP
server, tailored for my personal needs.

> Since you are using nginx as your frontend webserver you can still use Unix
> sockets to proxy HTTP requests to your backend handlers, just use a proxy
> interface instead of the fastcgi interface (I haven't added an async. fastcgi
> handler to lua-handlers Yet).

Yes, this is not a problem.

Alexander.