Re: WSAPI vs. events

[Alexander Gladysh <agladysh@...>]

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.

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

This is what my original question about.

Alexander.