in reply to Registering various app states at run-time

/proc is highly OS dependant and on most systems, AFAIK, only for communication with the kernel.

If you are writting some network server in a non blocking fashion (so, using select), you can use another TCP port or a Unix socket to serve the status (or if it is a web server, mapping it to a specific url).

If performance is what bothers you, you can use some shared memory module or use a ram file system (for instance, /tmp on Solaris).

You can also write status to disk only when a signal is sent to the process, but be carefull on how you handle signals from perl because it is easy to crash the app if you try to do something complex there that allocates memory.

Replies are listed 'Best First'.
Re^2: Registering various app states at run-time
by arkturuz (Curate) on Feb 13, 2006 at 13:04 UTC
    Well, it is a network server and already finished. I want to add this feature so that I can monitor it all the time with some second app. (Currently, server is writing errors and warnings to a log file.) I am considering using a Net::Shared module.
[reply]
      Net::Shared doesn't look like a good option to me. Looking at its source code I have found that it forks a new process that acts as a TCP server that is where state is maintained. The problem is that it is a blocking server an so, any stalled connection will cause your full server to stall.

      Besides that, the overhead could be actually higher than that of just writting the state to disk.

      Other modules like IPC::Shareable using shared memory should be a better option.

[reply]
        > Net::Shared doesn't look like a good option to me

        [download]
        I agree. I ran it's example programs and the client dies all the time with the message "Address already in use at ssrpt_c.pl line xx".

        I will try your suggestion.
        Thanks!

[reply]
[d/l]

In Section Seekers of Perl Wisdom