Re: WSAPI vs. events

[Alexander Gladysh <agladysh@...>]

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:
>> 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?

Sorry, I do not understand this paragraph.

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

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

Thanks,
Alexander.