Re: WSAPI vs. events

[Matthew Wild <mwild1@...>]

On 13 April 2011 21:03, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 16:45, Robert G. Jakabosky
> <bobby@sharedrealm.com> wrote:
>> On Wednesday 13, Alexander Gladysh wrote:
>>> On Wed, Apr 13, 2011 at 15:29, Louis Mamakos <louie@transsys.com> wrote:
>>> > On Apr 13, 2011, at 2:32 AM, Alexander Gladysh wrote:
>>> >> On Wed, Apr 13, 2011 at 03:58, Matthew Wild <mwild1@gmail.com> wrote:
>>> >>> On 13 April 2011 00:47, Alexander Gladysh <agladysh@gmail.com> wrote:
>>> >>>> On Sun, Apr 10, 2011 at 10:59, Alexander Gladysh <agladysh@gmail.com>
>> wrote:
>
>>> >>>>> Now I rotated the log file. How do I tell the WSAPI service to let go
>>> >>>>> old log file and open a new one?
>
>>> > If you have lfs available, perhaps you could periodically stat() the log
>>> > file pathname, and see if it's major/minor device numbers changed?  That
>>> > would allow you to detect that it has been renamed and a new file at the
>>> > name has replaced it.
>
>>> It will probably resolve the concrete problem with the log file, but
>>> will not help the problem in general. I do need to be able to send a
>>> message to a particular WSAPI fork and receive an immediate answer.
>
>> In that case how about having each WSAPI fork read from a named pipe (see
>> mkfifo):
>> /tmp/wsapi_<pid>.pipe
>
>> You can send it a message/event by writing to that file.  You will need to
>> make the FD non-blocking, since you wouldn't want to have the WSAPI process
>> block on the read.
>
> But how do I tell WSAPI to react on pipe changes immediately?
>
> The problem here is not a delivery of the message (for which there is
> a plenty ways to do it). The problem is how to force specific WSAPI
> process to react on this message immediately.
>
> Immediately: right now if idle, right after current handler is yielded
> if not. The problem is with idle option here.
>
>> Basically your WSAPI process is going to have to listen for your command
>> messages from somewhere.
>
> Yes.
>
>> Maybe it would help if you tell use a bit more about the types of
>> events/messages that you need to send to your WSAPI process.  What time
>> constraints are there on the processes response to those messages?  Does it
>> need to interrupt the running script NOW or at a set of sync. points?
>
> 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?

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

It's on my todo to see if something like this can be integrated into
LuaSignal, but I haven't had chance to look at it so far.

Regards,
Matthew