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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db6070970f45c3c6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-29 02:44:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: Francisco Javier Loma Daza Newsgroups: comp.lang.ada Subject: Re: Replicative Partitions Date: Mon, 29 Oct 2001 11:43:49 +0100 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: References: <9rctpj$t532j$1@ID-25716.news.dfncis.de> Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: avanie.enst.fr 1004352278 42370 137.194.161.2 (29 Oct 2001 10:44:38 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 29 Oct 2001 10:44:38 +0000 (UTC) To: comp.lang.ada@ada.eu.org Return-Path: In-Reply-To: <9rctpj$t532j$1@ID-25716.news.dfncis.de> X-Mailer: Spruce 0.7.4 for X11 w/smtpio 0.8.2 X-Virus-Scanned: by AMaViS perl-11 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk X-Reply-To: Francisco.Loma@isotrol.com List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:15336 Date: 2001-10-29T11:43:49+01:00 On Sat, 27 Oct 2001, Nick Roberts wrote: > Subject: Replicative Partitions > > I would appreciate views on the following. > > Annex E (of the RM95) seems to make the assumption that each partition > will > only be in execution solitarily, rather than there being several > instances > of one partition executing concurrently. Indeed, it describes things on > the > assumption (or at least from the viewpoint) of there being just one > 'program' running. The rationale does not add anything to this. > > This viewpoint may be sensible for a typical embedded system. However, in > a > system (any system?) which supports the dynamic initiation of the > execution > of partitions, several instances of one partition executing concurrently > seems to be at least a possibility. Furthermore, it may be very useful, > or > even vitally necessary that this is supported. > > For one thing, I suggest the wording of the RM95 should be changed (in > the > next revision) to explicitly reflect the possibility of the multiple > execution of a partition, which I shall term a "replicative partition". A > rule would be required, I suspect, that a partition is only permitted to > be > replicative if it has no shared passive library units nor RCI bodies > assigned to it. > > For another, if the Partition_ID attribute only statically identifies a > partition (the best interpretation to my mind), I suggest it would be > extremely useful to have a means of identifying instances of replicative > partitions, and for the next revision to specify this means. > > One possibility is a new language-defined package: > > package System.RPC.Replication is > > type Instance_ID is private; > > Null_Instance: constant Instance_ID; > > function "=" (Left, Right: in Instance_ID) return Boolean; > -- also "<", "<=", ">", and ">=" ? > > function Image (Instance: in Instance_ID) return String; > > -- possibly other operations of Instance_ID? > > function Current_Instance return Instance_ID; > > function Is_Terminated (Instance: in Instance_ID) return Boolean; > -- ? > function Is_Callable (Instance: in Instance_ID) return Boolean; -- > ? > > private > -- implementation defined > end; > > Each executional instance of any partition, regardless of which node in > the > network it is executing on, has a unique identifying value, of type > Instance_ID, called its 'instance identifier'. The function > Current_Instance > would return the instance identifier of the instance calling it. > > In addition, each remote subprogram (declared in a RCI) would have an > attribute Remote_Caller, which would yield the instance identifier of the > calling instance, within the body of that subprogram (and would be > illegal > elsewhere). > > This would provide the basis for servers to service multiple instances of > a > replicative partition separately, and, provided a caller could not 'fake' > its instance identifier to the server it was calling, it would provide > the > basis for any security scheme the server wished to impose. > > Needless to say, this is (roughly) the scheme I intend to implement for > AdaOS. > > I believe the word 'program' in the RM95 is used inconsistently, and that > its use is unnecessary and confusing. It would be better to leave the > informal meaning in 10.2 (2) and remove all other references to the word > or > concept of 'program' throughout the remainder of the RM95 (and simply > talk > about the execution of partitions instead). > > (a) Am I totally getting hold of the wrong end of the stick on this issue > (as I often do ;-) ? > > (b) Is this a matter that has been usefully discussed before? On c.l.a? > > (c) Would the scheme I propose be worth inclusion in the next revision of > the language, or is it a bit too esoteric (or poorly formed)? > > (d) Are there any further points related to this issue of which I should > be > aware? Well, I assume that your extension to Annex E is for making possible to have a client-server architecture, based only on packages/partition: - A server partition with the requiered RCIs/Shared_Passive packages - *Several* partitions acceding the server partition When I first looked at Annex E, I have the same question. If Partition_ID is unique along the distribuited program, I can't have several instantiantions of client partitions. I agree with you :) In practice, you can manage to do client-server, using a server partition on which client object get registered. On registration time, you can pass a password. An example package Abstract_Client is type Object is abstract limited null record; function Get_Password(this: Object) return String is abstract; end Client with Abstract_Client; package The_Server is procedure Register(client: access Abstract_Client.Object'Class); No_Grants: Exception; end The_Server; You can then run several clients to register. This way you do not need replication partition, just several objects, and you identify each one by a password.