Hello,
how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).
Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?
Wolfram
Wolfram Manthey wrote:
Hello,
how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?
Well there are three ways (possibly more) to do this:
The best way ™. Design a message based architecture for all of your
processes that includes a terminate message. Design your “master” process
as a resource manager that registers a prefix that all of your child
processes open(). Since all of your child processes will perform an
open() to your “master” process, you automatically have a list of all the
pids of your children (which you can do with as you like). When you child
processes terminate for any reason your “master” process will receive a
close on the prefix and can remove the process from it’s internal list or
restart it or whatever. When you wish to terminate a process, rather than
hit it with an asynchronous signal, send a synchronous terminate message
(note that other than the open, the children never send to the master
process). If your child process does not respond to the terminate message
THEN FIX IT (you wouldn’t believe how many times I have heard this as an
excuse for using signal based termination). This method is fully
synchronous and robust. This method does not require that your master
process actually spawn() the child processes (although it can).
The common unixy, but sucky way. Start all your child processes from
the master process and collect the pids into a list. Register a SIGCHLD
handler in your master process and either delete terminated processes from
your list or restart them. This method is asynchronous and (if not done
very carefully) non robust. This method requires that the “master”
process also spawn() the children.
The uncommon wacky way. Use the /proc interface to poll the currently
running process list (have some config file to let you know which process
names are “yours”), when you see a process disappear from the list imply
that it has died and remove it from your list, or restart. This method is
synchronous, and low performance, and should be relatively easy to make
robust. This method does not require that the “master” process spawn()
the children, although it can.
Oddball combinations of 1,2,3 ?
I have implemented and maintained design number 1, and had to maintain 2,
and number 1 is much more robust, and easy to maintain. I have never
tried number 3, since it simply goes against my (exception based) grain.
To answer your question on the proc interface, goto cvs.qnx.com, and
download the source for pidin. It will answer all your questions.
Rennie
“Rennie Allen” <rallen@csical.com> wrote in message
news:bfjqsp$ob3$1@tiger.openqnx.com…
Wolfram Manthey wrote:
Hello,
how can I figure out, what processes (PIDs) are running at the moment
and what are their name out of my own program? Need to check what
processes are running and to terminate some of them when they’re running
out of my process (similar to pidin and slay on command line).Do I have to parse the contents of /proc ? If, then how to know what
process stands behind the pid?Well there are three ways (possibly more) to do this:
The best way ™. Design a message based architecture for all of your
processes that includes a terminate message. Design your “master” process
as a resource manager that registers a prefix that all of your child
processes open(). Since all of your child processes will perform an
open() to your “master” process, you automatically have a list of all the
pids of your children (which you can do with as you like). When you child
processes terminate for any reason your “master” process will receive a
close on the prefix and can remove the process from it’s internal list or
restart it or whatever. When you wish to terminate a process, rather than
hit it with an asynchronous signal, send a synchronous terminate message
(note that other than the open, the children never send to the master
process). If your child process does not respond to the terminate message
THEN FIX IT (you wouldn’t believe how many times I have heard this as an
excuse for using signal based termination). This method is fully
synchronous and robust. This method does not require that your master
process actually spawn() the child processes (although it can).The common unixy, but sucky way. Start all your child processes from
the master process and collect the pids into a list. Register a SIGCHLD
handler in your master process and either delete terminated processes from
your list or restart them. This method is asynchronous and (if not done
very carefully) non robust. This method requires that the “master”
process also spawn() the children.The uncommon wacky way. Use the /proc interface to poll the currently
running process list (have some config file to let you know which process
names are “yours”), when you see a process disappear from the list imply
that it has died and remove it from your list, or restart. This method is
synchronous, and low performance, and should be relatively easy to make
robust. This method does not require that the “master” process spawn()
the children, although it can.Oddball combinations of 1,2,3 ?
I have implemented and maintained design number 1, and had to maintain 2,
and number 1 is much more robust, and easy to maintain. I have never
tried number 3, since it simply goes against my (exception based) grain.To answer your question on the proc interface, goto cvs.qnx.com, and
download the source for pidin. It will answer all your questions.Rennie
Is there a standard way for the master process to get the names of the other
processes with the first method you outlined?.
JV wrote:
Is there a standard way for the master process to get the names of the other
processes with the first method you outlined?.
You must mean in the case where the master process does not spawn the children,
since obviously, if it is spawning the children it must know their names (since
it gives them their “names” - i.e. argv[0]).
In the case where the master does not spawn the processes the /proc interface
can be used to obtain the name of the executable associated with the pid. I
guess the question is, since the pid of the process is already resolved, of what
additional value is the name of the executable associated with the process ?
Rennie
Yes, I was referring to the case where the master does not spawn the
children.
I was considering the case where the master process must react to a process
terminating, and must react differently depending on which process
terminated. I think the name of the executable is not an ideal way to ID
the process. Perhaps another standard message, in addition to the terminate
message, would facilitate this.
Thanks,
Jon
“Rennie Allen” <rgallen@attbi.com> wrote in message
news:bfu7b3$aa4$1@inn.qnx.com…
JV wrote:
Is there a standard way for the master process to get the names of the
other
processes with the first method you outlined?.You must mean in the case where the master process does not spawn the
children,
since obviously, if it is spawning the children it must know their names
(since
it gives them their “names” - i.e. argv[0]).In the case where the master does not spawn the processes the /proc
interface
can be used to obtain the name of the executable associated with the pid.
I
guess the question is, since the pid of the process is already resolved,
of what
additional value is the name of the executable associated with the process
?Rennie