comp.lang.ada
 help / color / mirror / Atom feed
From: Michael Lamarre <usdmike@yahoo.com>
Subject: Re: Help with a Remote Type / Iterator
Date: Mon, 01 Dec 2003 13:37:44 GMT
Date: 2003-12-01T13:37:44+00:00	[thread overview]
Message-ID: <IuHyb.47733$Gj.31467@twister.socal.rr.com> (raw)
In-Reply-To: <LqCdnbdsi6KuT1eiRVn-sQ@comcast.com>

Robert I. Eachus wrote:

> This is not necessarily a solution, just trying to understand what you 
> are doing....
> 
> Do you really require that your iterator run on processor A, accessing 
> objects from processor B?  If so it can be done.  But as you sort of 
> point out, the problem is that you are trying to cram everything into 
> one package.

I'm not sure that it is *required*, but that is the approach my mentor 
has been pushing, and it seemed to make some sense, so I was going 
along. I only started learning Ada about 4 or 5 months ago. Classwide 
types is one of the areas that I'm still not solid on.

> 
> If you really need the data transfered from processor to processor, you 
> will need to provide 'Read and 'Write.  These can be defined in terms of 
> the subcomponents for the actual type, see the Rationale, I think for 
> details.
> 
> But I really suspect that you are confusing (in the other meaning of 
> confusing--mixing them together) two different things, a type which is a 
> remote type, and a local iterator over collections of objects of the 
> type.  If the collections are distributed, you have a big design job 
> just defining what iteration means.  (Do you want to iterate over a 
> snapshot of the container state, iterate over all the objects in a 
> particular partition, then do the next partition, iterate over all 
> partitions in parallel, or is there other implicit order of iteration, 
> etc.)
> 

Basically, this program is a client/server program. One server, many 
clients. The server will piece together these COLLECTION_TYPEs, stick 
them in a protected structure, and then the clients will come by and 
process them. But each COLLECTION_TYPE must have its constituent 
elements processed in order. The collection will NOT be modified by the 
server once it is placed into the protected structure for the clients to 
retrieve it from.

It almost sounds like you think that we're doing REMOTE_TYPES for the 
wrong reasons. That is something I started to wonder the other day. If 
it is such a pain in the butt to iterate over a distributed object, 
perhaps that's for a reason? (i.e., you shouldn't) Like I said, I'm 
still not entirely comfortable with classwide types, so I'm not really 
sure how to tell what types you would want to make REMOTE_TYPES and 
which to leave normal and just write 'Read and 'Write for. Are there any 
rules of thumb as to when it is appropriate to make a type a remote 
type? Thanks for your help.

-- Mike L.




  reply	other threads:[~2003-12-01 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-01  3:48 Help with a Remote Type / Iterator Michael Lamarre
2003-12-01  5:31 ` Robert I. Eachus
2003-12-01 13:37   ` Michael Lamarre [this message]
2003-12-02 23:17     ` Robert I. Eachus
2003-12-03  4:46       ` Michael Lamarre
2003-12-01 23:00 ` Nick Roberts
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox