Akintayo,
You could use the fvwm95 solution : pipes. This may not be
applicable in your case, but here is how it works :
For this to work, you have to have control over the process that
forks the process you want to monitor for crashes. Under fvwm95, fvwm95
creates two pipes. The fd's for these are passed to the fvwm95 modules
(which are spawned by fvwm95, and are the processes being monitored). Now,
fvwm95 closes one end of one pipe making it a pipe through which data
flows from fvwm95 to the modules. The module closes the opposite end of
the other pipe making it a pipe through which data flows from the module
to fvwm95. Thus two-way communication now exists between fvwm95 and the
module.
The keys fact is that if you write to a pipe which has been
cannot be read from, SIGPIPE is generated. Thus, when the module crashes,
anything that fvwm95 writes to the pipe which carries data from fvwm95 to
the module will cause SIGPIPE. This signal is trapped and processed by
fvwm95, making it aware that the module has crashed.
How can you make this solution work for you? The process you are
interested in should be spawned by a monitor program that creates the
pipes. This should have an signal handler that is capable of handling the
SIGPIPE signal. If you do what fvwm95 does with the pipes, I think you
will have a workable solution.
This being said, you can probably think up equivalent solutions
using other forms of IPC.
Regards,
Kenneth
There is no such thing as luck. 'Luck' is nothing but an absence of bad luck.
On Sat, 3 Apr 1999, Akintayo Holder wrote:
> Is there a way of telling if a program is not responding ?
> A sure way of differentiating between a hung program and a slow one ala
> widows.
>
> --
> WI 2 Aus 1
> Ice Cube
> RH5.2 Personal 17728385
> http://www.bigfoot.com/~blakdogg
>
