Re: WSAPI vs. events

[Alexander Gladysh <agladysh@...>]

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

Basically, the requirements are the same as if I delivered the message
via HTTP request. The only problem is that I can't target that request
to a specific one of the fork processes, if they are listening on the
same UDS socket. (And I can't have a guaranteed request delivery to
every one fork process, which would be enough in my case — without
residing to, say, spamming socket and counting number of unique
replies.)

> For the log file, it sounds like your are trying to make sure that 100% of the
> requests get logged to the log file.  If that is the case it might be better
> to have a log daemon collect the log messages from the WSAPI process over TCP,
> then you can have the log daemon handle the log rotation at a fixed interval
> or after it grows to a set size.

Again, this is a solution for concrete problem.

Here are more examples for messages:

-- Rotate log file (just discussed this)
-- Shutdown (to be restarted by watchdog)
-- Report usage statistics
-- Change GC constants.

Thanks,
Alexander.