[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: WSAPI vs. events
- From: Matthew Wild <mwild1@...>
- Date: Wed, 13 Apr 2011 22:16:56 +0100
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.
>> 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.
Regards,
Matthew