sproc FOLLOW-UP

New Message Reply Date view Thread view Subject view Author view

Tom Impelluso (verdi++at++piano.ucsd.edu)
Wed, 16 Jul 1997 09:27:05 -0700


Hello,

This is a follow-up to my question on sproc() vs fork() with Performer.

I have now learned that an Octane has only two CPU's ;-)

next...

Basically, there will be two codes:
finite_element.c
performer.c

(FYI: finite_element is an INTENSE numerical algorithm)

They need to talk.

First question:

Should I have a main that will sproc/fork BOTH finite_element.c
and performer.c
OR
Should performer.c's main() sprock/fork the finite_element.c
Should finite_element.c's main() sprock/fork the performer.c

That is really stated for rhetorical reasons...
I must admit it is an issue I alone must think about and few can
advise, but I thought I would toss it out.

However, in that context, this question may be more meaninful,
and is troubling me...

Suppose I used fork()
The main would fork() and exec()
the performer() and the finite_element().

But, then, I would have to have shared memory set up to allow the
finite_element() and the perfomer() to communicate.

Then, someone suggested sproc().

As I understand, sproc() is like fork(), but the sproc()'ed process is
in the same address space. Thus, I can obviate the necessity for
shared memory. and all that expensive overhead.

But, from what I read, sproc() is "like" a lightweight thread.

Thus, I would ASSSUME that sproc() is "designed" for such a purpose;
i.e. LIGHTweight.

Now, my spine tingles when I envision finite_element() as a lightweight
process --- far from it. It is a huge algorithm with MANY MANY variables.

However, so far, it seems that having the performer.c sproc() the
finite_element.c seems reasonable; seems like it should work.

But I fear that I will shortly collide with some internal design problem...
afterall, in a strict philosophical sense, I am using sproc() to
create a child that is VERY FAR from being a lightweight process.

i.e. I assume sproc CAN be in the same address space but only BECAUSE
it tacitly assumes the sproc`d code will be SMALLER than the daddy.
and that assumption of a smaller child is intinsic to the success of sproc().

Could you tell me if I will encounter a problem?
Should I stick with fork() and shared memory?

Tom

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:37 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.