Re: WSAPI vs. events

["Robert G. Jakabosky" <bobby@...>]

On Wednesday 13, Alexander Gladysh wrote:
> On Thu, Apr 14, 2011 at 01:16, Matthew Wild <mwild1@gmail.com> wrote:
> > On 13 April 2011 21:38, Alexander Gladysh <agladysh@gmail.com> wrote:
> >> On Thu, Apr 14, 2011 at 00:31, Matthew Wild <mwild1@gmail.com> wrote:
> >>> On 13 April 2011 21:03, Alexander Gladysh <agladysh@gmail.com> wrote:
> >>>> No hard real-time requirements. If WSAPI is busy handling request, my
> >>>> message can wait. If it is idle, message should be processed
> >>>> immediately (OK, within a second, if you want some breathing space —
> >>>> but such large delay would be ugly, it is uncalled for).
> >>> 
> >>> Ok, so the processes are waiting for something from the WSAPI
> >>> connection. Do you know if this is using select() or similar? or a
> >>> blocking connection?
> >> 
> >> Sorry, I do not understand this paragraph.
> > 
> > Then you're probably not going to be able to implement it without some
> > work.
> > 
> > Most network applications that need to react to multiple things use a
> > mechanism such as the select() function. It takes a list of sockets,
> > and waits until one or more of them are ready for reading/writing. If
> > running strace on your workers show them hung in select(), this is the
> > case.
> > 
> > Alternatively they could be doing blocking reads, strace will show
> > them blocking in read() until data becomes available.
> > 
> > If they are using the select() approach then you simply need to add a
> > new socket to the list that select() is watching, and write to this
> > socket in the signal handler when it is fired. Then select() will
> > return, you can see a signal must have fired and handle it
> > appropriately. This is all because it is not safe to access the Lua
> > state from a signal handler by the way. I believe even libevent
> > handles signals this way too.
> 
> Matthew, thank you, I do know what select() is. Sorry for not being clear.
> 
> I do not understand the first sentence:
> >>> Ok, so the processes are waiting for something from the WSAPI
> >>> connection.
> 
> What processes are you talking about?
> 
> >>> If the former, the typical solution is to use signals and have the
> >>> signal handler write (e.g. a byte) to a socket that is waited on with
> >>> select(). This wakes up the process and it can read the data from the
> >>> signal handler's socket and perform the appropriate action (re-open
> >>> log file, re-read config, ...).
> >> 
> >> There are several (like 10) WSAPI forks listening on the single UDS
> >> socket. If I write to socket, only a random (?) one of 10 forks will
> >> receive message. I need to poke a specific fork (or all of them,
> >> whichever is easier to do). I do not want to go probabilistic and send
> >> pokes until I get a response from the process I need.
> > 
> > Yes, I mean a different socket, not the WSAPI one.
> 
> Sorry, but I do not understand this.

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.

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.

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

1. http://lua-users.org/lists/lua-l/2004-06/msg00586.html
2. https://github.com/Neopallium/lua-handlers
3. https://github.com/Neopallium/lua-
handlers/blob/master/examples/http_server.lua

-- 
Robert G. Jakabosky