Starting Multiple Processes

Hello,

I would like to start one main process, which in turns starts three other
processes, all of which will eventually talk with each other. Can anyone
point me in the right direction with respect to functions that need to be
called for starting simultaneous processes. Thus far, it seems fork,spawn
only create a duplicate copy of the parent process, and exec replaces the
current parent process with another one. I’d like to have multiple ones
running at once.

Thanks!
Matt.

Mathew Asselin <m2asselin@yahoo.com> wrote:

Hello,

I would like to start one main process, which in turns starts three other
processes, all of which will eventually talk with each other. Can anyone
point me in the right direction with respect to functions that need to be
called for starting simultaneous processes. Thus far, it seems fork,spawn
only create a duplicate copy of the parent process, and exec replaces the
current parent process with another one. I’d like to have multiple ones
running at once.

The spawn*() are your best bet – their normal behaviour is to load a
new program into a new process. The traditional Unix way is to do
a fork(), then in the child exec() into the new program. spawn() is,
essentially, the fork & exec as a single operation, making it far
more efficient.

-David

Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:
DG > Mathew Asselin <m2asselin@yahoo.com> wrote:

Hello,

I would like to start one main process, which in turns starts three other
processes, all of which will eventually talk with each other. Can anyone
point me in the right direction with respect to functions that need to be
called for starting simultaneous processes. Thus far, it seems fork,spawn
only create a duplicate copy of the parent process, and exec replaces the
current parent process with another one. I’d like to have multiple ones
running at once.

DG > The spawn*() are your best bet – their normal behaviour is to load a
DG > new program into a new process. The traditional Unix way is to do
DG > a fork(), then in the child exec() into the new program. spawn() is,
DG > essentially, the fork & exec as a single operation, making it far
DG > more efficient.

What he said.

But something else caught my eye in your original question. You said “all
the programs would talk to each other”. If they are single threaded,
beware of a deadly embrace.

I.E. Process A sends to process B. Process B sends to process A. Now both
processes are hung waiting for the othr to reply. This can just as easily
happen with 3 or more processes. You need to come up with a hierarchy(sp)?
where A only sends to B (i.e. B never sends to A, but it can reply to A),
and B can send to C (C never sends to B). (Or perhaps A can send to A and B
but they can only reply to A. AND, they can’t send to each other.) If you
need to get a message in the other direction you can use a Pulse(). Pulses
don’t block.

So now, if B wants to send to A it sends a pulse. A receives the pulse and
sends back a message to B saying essentially, “Hi B. What’s Up?” Now B is
free to REPLY to A’s message by sending it’s own message. When A is ready
to reply to B’s message (sent as a reply) it sends a new message and B
simply replies with a Done or Thanks or even a NULL message.

On 2004-05-14 17:34:24 +0200, Bill Caroselli <qtps@earthlink.net> said:

David Gibbs <> dagibbs@qnx.com> > wrote:
DG > Mathew Asselin <> m2asselin@yahoo.com> > wrote:
Hello,

I would like to start one main process, which in turns starts three other
processes, all of which will eventually talk with each other. Can anyone
point me in the right direction with respect to functions that need to be
called for starting simultaneous processes. Thus far, it seems fork,spawn
only create a duplicate copy of the parent process, and exec replaces the
current parent process with another one. I’d like to have multiple ones
running at once.

DG > The spawn*() are your best bet – their normal behaviour is to load a
DG > new program into a new process. The traditional Unix way is to do
DG > a fork(), then in the child exec() into the new program. spawn() is,
DG > essentially, the fork & exec as a single operation, making it far
DG > more efficient.

What he said.

But something else caught my eye in your original question. You said “all
the programs would talk to each other”. If they are single threaded,
beware of a deadly embrace.

I.E. Process A sends to process B. Process B sends to process A. Now both
processes are hung waiting for the othr to reply. This can just as
easily happen with 3 or more processes. You need to come up with a
hierarchy(sp)?
where A only sends to B (i.e. B never sends to A, but it can reply to A),
and B can send to C (C never sends to B). (Or perhaps A can send to A and B
but they can only reply to A. AND, they can’t send to each other.) If you
need to get a message in the other direction you can use a Pulse(). Pulses
don’t block.

So now, if B wants to send to A it sends a pulse. A receives the pulse and
sends back a message to B saying essentially, “Hi B. What’s Up?” Now B is
free to REPLY to A’s message by sending it’s own message. When A is
ready to reply to B’s message (sent as a reply) it sends a new message
and B simply replies with a Done or Thanks or even a NULL message.

This is interesting indeed.
This helps me solve part of a related problem.

I have to write an application with an FDIR implemented as a process
whose responsabilities are

  • reseting an hardware watchdog (HRT constraint)
  • monitoring the health status of other processes P1 … Pn (being a
    UNIX guy, I planed to use signals with USR1 and USR2)
  • starting/stoping P1 … Pn
    in order to save downtime when one of the Pi failed (having to reload
    it from solid state memory requires too much time), I plan at startup
    to launch the FDIR and all the Pi plus for every Pi have a P’i process
    in memory not elected until Pi fails. The problem is that I do not know
    how to suspend/elect a process given its PID (I can’t find the right
    system call)
  • monitor the integrity of data stored in common memory area (probably
    using a CRC32)

All of this stuff has to run on a PC104 486@100Mhz 32MB RAM

Any suggestion, comments, recomendations on how to solve the
suspend/election problem and on the general robustness of this solution
?

A+
Lionel

################################################
Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
trollhunter@free.fr
http://www.tldp.prg/HOWTO/SPARC-HOTO.html

trollhunter <trollhunter@linuxfr.org> wrote in message
news:2004051419523650073%trollhunter@linuxfrorg…

  • monitoring the health status of other processes P1 … Pn (being a
    UNIX guy, I planed to use signals with USR1 and USR2)
  • starting/stoping P1 … Pn
    in order to save downtime when one of the Pi failed (having to reload
    it from solid state memory requires too much time), I plan at startup
    to launch the FDIR and all the Pi plus for every Pi have a P’i process
    in memory not elected until Pi fails. The problem is that I do not know
    how to suspend/elect a process given its PID (I can’t find the right
    system call)

Send a SIGSTOP to suspend and a SIGCONT to let it go would probably
do it. Your Px process must designed to avoid any race condition.

I would suggest to have a copy of Px in /dev/shmem and spawn() it
from there. That hopefully quick enough to meet your request.

-xtang

On 2004-05-16 04:41:55 +0200, “Xiaodan Tang” <xtang@qnx.com> said:

trollhunter <> trollhunter@linuxfr.org> > wrote in message
news:2004051419523650073%trollhunter@linuxfrorg…

  • monitoring the health status of other processes P1 … Pn (being a
    UNIX guy, I planed to use signals with USR1 and USR2)
  • starting/stoping P1 … Pn
    in order to save downtime when one of the Pi failed (having to reload
    it from solid state memory requires too much time), I plan at startup
    to launch the FDIR and all the Pi plus for every Pi have a P’i process
    in memory not elected until Pi fails. The problem is that I do not know
    how to suspend/elect a process given its PID (I can’t find the right
    system call)

Send a SIGSTOP to suspend and a SIGCONT to let it go would probably
do it. Your Px process must designed to avoid any race condition.
Yes, in the design phase there is some schdulability analysis going on > :slight_smile:



I would suggest to have a copy of Px in /dev/shmem and spawn() it
from there. That hopefully quick enough to meet your request.
OK,

For monitoring the health status (kinda ping/pong) I am still hesiting
between pulses and signals even after reading the long thread on this
subject.

-xtang
Thanks for your answer.

A+
Lionel

################################################
Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
trollhunter@free.fr
http://www.tldp.prg/HOWTO/SPARC-HOTO.html

trollhunter <trollhunter@linuxfr.org> wrote:
t > OK,
t > For monitoring the health status (kinda ping/pong) I am still hesiting
t > between pulses and signals even after reading the long thread on this
t > subject.

You mentioned in your previous post that part of the reasoning to this is
to automatically jump start a failed system. If you use pulses and your
program gets caught in an errent loop, it may never get around to reading
an outstanding pulse. It will almost always be able to process a signal
(unless you specifically choose to ignore it).

On 2004-05-17 16:35:58 +0200, Bill Caroselli <qtps@earthlink.net> said:

trollhunter <> trollhunter@linuxfr.org> > wrote:
t > OK,
t > For monitoring the health status (kinda ping/pong) I am still
hesiting t > between pulses and signals even after reading the long
thread on this t > subject.

You mentioned in your previous post that part of the reasoning to this
is to automatically jump start a failed system. If you use pulses and
your program gets caught in an errent loop, it may never get around to
reading
an outstanding pulse. It will almost always be able to process a
signal (unless you specifically choose to ignore it).
OK, thanks for the informations.

A+
Lionel

################################################
Lionel, trollhunter Bouchpan-Lerust-Juery
trollhunter@linuxfr.org
trollhunter@free.fr
http://www.tldp.prg/HOWTO/SPARC-HOTO.html