From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3c64340c2da5d832,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-04-08 08:55:05 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!logbridge.uoregon.edu!arclight.uoregon.edu!newsfeed.cs.utexas.edu!geraldo.cc.utexas.edu!not-for-mail
From: "Bobby D. Bryant" <bdbryant@mail.utexas.edu>
Newsgroups: comp.lang.ada
Subject: Q re glade for slaves.
Date: Sun, 08 Apr 2001 09:56:07 +0600
Organization: (I do not speak for) The University of Texas at Austin (nor they
 for
 me).
Message-ID: <3ACFE157.E58FF313@mail.utexas.edu>
NNTP-Posting-Host: dial-19-5.ots.utexas.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: geraldo.cc.utexas.edu 986745263 23842 128.83.128.69 (8 Apr 2001
 15:54:23 GMT)
X-Complaints-To: abuse@cc.utexas.edu
NNTP-Posting-Date: 8 Apr 2001 15:54:23 GMT
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-0.1.49 i686)
X-Accept-Language: en,fr,de
Xref: supernews.google.com comp.lang.ada:6646
Date: 2001-04-08T15:54:23+00:00
List-Id: <comp.lang.ada>

I've just started in on distributed programming, and I can modify some
of the gnat-glade examples to do what I need (structurally), but the
solution I came up with doesn't seem very elegant, so I wonder if anyone
has a better suggestion before I get too far in to it.

I need a master and some number of slaves.  The slaves will all execute
identical code on different data, and their work is very CPU-intensive,
so I would like to run each slave on a different processor.  In most
cases I will simply let the number of processors available dictate the
number of slaves to be used.  The master will communicate with the
slaves intermittently while the distributed job runs, and do a bit of
collation when the slaves are all finished with their share of the
work.  The slaves do not need to share any common state.  (FYI, this is
not a non-terminating server system; rather, for each run of the job it
will start, run for a few hours, and be finished.)

The solution that I came up with is to create a generic package for the
common code for the slaves, create an instance of that package for each
slave, and have the .cfg file assign each instance to a different
processor.  However, since the Remote_Call_Interface pragma seems to
apply to library units rather than to instances of a generic package
that can be created at run time, my solution means I have to decide in
advance how many slaves I want, and provide a separate file to
instantiate each one.

This is not a show-stopper, because changing the number of slaves this
way is a very small amount of work.  However, I would be surprised if
something more flexible is not possible.  Am I missing something?

Thanks,

Bobby Bryant
Austin, Texas