Re: [Q]: Distributed System Annex DSA

Re: [Q]: Distributed System Annex DSA

[Douglas Rupp]

Reposting article removed by rogue canceller.

Robert A Duff <bobduff@world.std.com> wrote:
>Any sufficiently advanced technogoy is indistinguishable from magic.
>Who said that?  ;-)"

This sounds like the sci fi author E. E. "Doc" Smith.

Re: [Q]: Distributed System Annex DSA

[Mike Stark]

Douglas Rupp wrote:
> 
> Reposting article removed by rogue canceller.
> 
> Robert A Duff <bobduff@world.std.com> wrote:
> >Any sufficiently advanced technogoy is indistinguishable from magic.
> >Who said that?  ;-)"
> 
> This sounds like the sci fi author E. E. "Doc" Smith.

I thought it was Arthur Clarke who said that -- although he could have
been quoting Smith.

Re: [Q]: Distributed System Annex DSA

[Art Schwarz]

(Secondary reference) In "Windows 95 Unleashed", one of the
authors has this quote. I believe taht the cited author was
Heinlein.

art schwarz

(My opinions are my wifes.)

Re: [Q]: Distributed System Annex DSA

[Mark A Biggar]

In article <R.Dy3uCq.757@beaver.cs.washington.edu> drupp@cs.washington.edu (Douglas Rupp) writes:
>Reposting article removed by rogue canceller.
>Robert A Duff <bobduff@world.std.com> wrote:
>>Any sufficiently advanced technologoy is indistinguishable from magic.
>>Who said that?  ;-)"
>This sounds like the sci fi author E. E. "Doc" Smith.

This is Clarke's law after the SF author Arthur C. Clarke. It is usually
followed by two colloraries:

Any sufficiently advanced magic is indistinguishable from technology.
	-- Gandalf's comment on Clarke's Law.

And Neither is distinguishable from a rigged demo.
	-- the unknown hacker.

--
Mark Biggar
mab@wdl.lmco.com

Re: [Q]: Distributed System Annex DSA

[Alan Brain]

Douglas Rupp wrote:
> 
> Reposting article removed by rogue canceller.
> 
> Robert A Duff <bobduff@world.std.com> wrote:
> >Any sufficiently advanced technogoy is indistinguishable from magic.
> >Who said that?  ;-)"
> 
> This sounds like the sci fi author E. E. "Doc" Smith.

No, it's Clarke's Law. Arthur C. Clarke, lately of the UK, currently
of Sri Lanka.

----------------------      <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling Maerklin Wagons, in 1/220 Scale

Re: [Q]: Distributed System Annex DSA

[Douglas Rupp]

Robert A Duff <bobduff@world.std.com> wrote:
>Any sufficiently advanced technogoy is indistinguishable from magic.
>Who said that?  ;-)"

This sounds like the sci fi author E. E. "Doc" Smith.

[Q]: Distributed System Annex DSA

[Jonas Nygren]

For Gnat there now is a release of support for DSA. So I thought
it was time to get an understanding what DSA can do for me. I have
a few questions around this topic after trying to understand what
the Rational and the RM's texts on this feature. (If you can point me
to some more good educational text for DSA I would appreciate that.)

Now to my questions for which I use the example of Tape_Driver given
in Annex E of the RM. I attach the code from the RM at the end of
this posting.

1)  When I studied this example I got the impression that the three
    parts Name_Server, Tape_Server and Tape_Client all could run
    in different partitions (and on different nodes). What confuses
    me is that the Name_Server does not have any 'pragma 
    Remote_Call_Interface' and in the explaining text it is referred
    to as a 'normal package'. Does this imply that Tape_Client and
    Tape_Server must be co-located in the same partition? If not,
    how does the compiler know that Tape_Server's interfaces 
    (Copy, Rewind) should be constructed to receive remote calls?

2)  I have come to regard the package Tapes as the 'contract' of
    a tape service. Would this be the right place to enforce 
    constraint and state checks to strengthen the consistency
    of the interface. State information would then be stored in
    the Tape (tagged) record. Are there any negative consequences
    in this approach and are there better ways to do this? 

3)  With CORBA and other similar technologies there is often much
    discussions on the need for threads in servers. My third question
    is about if and how one can use Ada tasks to achieve this in
    one remote active partition.

    One example in the Rationale showed how one could link together
    a number of active Worker partitions with a Controller partition
    and how these partitions could be distributed on different nodes.
    But nothing with tasks involved.

    My question is really if it is possible to multi-plex several
    service sessions on one partition. E.g. If Client A and B issues
    requests to the server 'at the same time' - how do I design the
    server so that these two calls can be overlapping and executed in
    parallel.

Any help appreciated!

Thanks in advance,

/jonas

-- Tape example from Ada RM e.4.2

(2)
       package Tapes is
          pragma Pure(Tapes);
          type Tape is abstract tagged limited private;
          -- Primitive dispatching operations where
          -- Tape is controlling operand
          procedure Copy (From, To : access Tape; Num_Recs : in Natural)
is abstract;
          procedure Rewind (T : access Tape) is abstract;
          -- More operations
       private
          type Tape is ...
       end Tapes;
(3)
       with Tapes;
       package Name_Server is
          pragma Remote_Call_Interface;
          -- Dynamic binding to remote operations is achieved
          -- using the access-to-limited-class-wide type Tape_Ptr
          type Tape_Ptr is access all Tapes.Tape'Class;
          -- The following statically bound remote operations
          -- allow for a name-server capability in this example
          function  Find     (Name : String) return Tape_Ptr;
          procedure Register (Name : in String; T : in Tape_Ptr);
          procedure Remove   (T : in Tape_Ptr);
          -- More operations
       end Name_Server;
(4)
       package Tape_Driver is
         -- Declarations are not shown, they are irrelevant here
       end Tape_Driver;
(5)
       with Tapes, Name_Server;
       package body Tape_Driver is
          type New_Tape is new Tapes.Tape with ...
          procedure Copy
           (From, To : access New_Tape; Num_Recs: in Natural) is
          begin
            . . .
          end Copy;
          procedure Rewind (T : access New_Tape) is
          begin
             . . .
          end Rewind;
          -- Objects remotely accessible through use
          -- of Name_Server operations
          Tape1, Tape2 : aliased New_Tape;
       begin
          Name_Server.Register ("NINE-TRACK",  Tape1'Access);
          Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
       end Tape_Driver;
(6)
       with Tapes, Name_Server;
       -- Tape_Driver is not needed and thus not mentioned in the
with_clause
       procedure Tape_Client is
          T1, T2 : Name_Server.Tape_Ptr;
       begin
          T1 := Name_Server.Find ("NINE-TRACK");
          T2 := Name_Server.Find ("SEVEN-TRACK");
          Tapes.Rewind (T1);
          Tapes.Rewind (T2);
          Tapes.Copy (T1, T2, 3);
       end Tape_Client;

Re: [Q]: Distributed System Annex DSA

[Jonas Nygren]

I referred to the wrong package in my first question which
made it self answering. Pls see below for correction.

Jonas Nygren wrote:
> 
> For Gnat there now is a release of support for DSA. So I thought
> it was time to get an understanding what DSA can do for me. I have
> a few questions around this topic after trying to understand what
> the Rational and the RM's texts on this feature. (If you can point me
> to some more good educational text for DSA I would appreciate that.)
> 
> Now to my questions for which I use the example of Tape_Driver given
> in Annex E of the RM. I attach the code from the RM at the end of
> this posting.
> 
> 1)  When I studied this example I got the impression that the three
>     parts Name_Server, Tape_Server and Tape_Client all could run
>     in different partitions (and on different nodes). What confuses
>     me is that the Name_Server does not have any 'pragma

                      ^ ^  Ouch, it should have been Tape_Server

>     Remote_Call_Interface' and in the explaining text it is referred
>     to as a 'normal package'. Does this imply that Tape_Client and
>     Tape_Server must be co-located in the same partition? If not,
>     how does the compiler know that Tape_Server's interfaces
>     (Copy, Rewind) should be constructed to receive remote calls?
> 
> 2)  I have come to regard the package Tapes as the 'contract' of
>     a tape service. Would this be the right place to enforce
>     constraint and state checks to strengthen the consistency
>     of the interface. State information would then be stored in
>     the Tape (tagged) record. Are there any negative consequences
>     in this approach and are there better ways to do this?
> 
> 3)  With CORBA and other similar technologies there is often much
>     discussions on the need for threads in servers. My third question
>     is about if and how one can use Ada tasks to achieve this in
>     one remote active partition.
> 
>     One example in the Rationale showed how one could link together
>     a number of active Worker partitions with a Controller partition
>     and how these partitions could be distributed on different nodes.
>     But nothing with tasks involved.
> 
>     My question is really if it is possible to multi-plex several
>     service sessions on one partition. E.g. If Client A and B issues
>     requests to the server 'at the same time' - how do I design the
>     server so that these two calls can be overlapping and executed in
>     parallel.
> 
> Any help appreciated!
> 
> Thanks in advance,
> 
> /jonas
> 
> -- Tape example from Ada RM e.4.2
> 
> (2)
>        package Tapes is
>           pragma Pure(Tapes);
>           type Tape is abstract tagged limited private;
>           -- Primitive dispatching operations where
>           -- Tape is controlling operand
>           procedure Copy (From, To : access Tape; Num_Recs : in Natural)
> is abstract;
>           procedure Rewind (T : access Tape) is abstract;
>           -- More operations
>        private
>           type Tape is ...
>        end Tapes;
> (3)
>        with Tapes;
>        package Name_Server is
>           pragma Remote_Call_Interface;
>           -- Dynamic binding to remote operations is achieved
>           -- using the access-to-limited-class-wide type Tape_Ptr
>           type Tape_Ptr is access all Tapes.Tape'Class;
>           -- The following statically bound remote operations
>           -- allow for a name-server capability in this example
>           function  Find     (Name : String) return Tape_Ptr;
>           procedure Register (Name : in String; T : in Tape_Ptr);
>           procedure Remove   (T : in Tape_Ptr);
>           -- More operations
>        end Name_Server;
> (4)
>        package Tape_Driver is
>          -- Declarations are not shown, they are irrelevant here
>        end Tape_Driver;
> (5)
>        with Tapes, Name_Server;
>        package body Tape_Driver is
>           type New_Tape is new Tapes.Tape with ...
>           procedure Copy
>            (From, To : access New_Tape; Num_Recs: in Natural) is
>           begin
>             . . .
>           end Copy;
>           procedure Rewind (T : access New_Tape) is
>           begin
>              . . .
>           end Rewind;
>           -- Objects remotely accessible through use
>           -- of Name_Server operations
>           Tape1, Tape2 : aliased New_Tape;
>        begin
>           Name_Server.Register ("NINE-TRACK",  Tape1'Access);
>           Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
>        end Tape_Driver;
> (6)
>        with Tapes, Name_Server;
>        -- Tape_Driver is not needed and thus not mentioned in the
> with_clause
>        procedure Tape_Client is
>           T1, T2 : Name_Server.Tape_Ptr;
>        begin
>           T1 := Name_Server.Find ("NINE-TRACK");
>           T2 := Name_Server.Find ("SEVEN-TRACK");
>           Tapes.Rewind (T1);
>           Tapes.Rewind (T2);
>           Tapes.Copy (T1, T2, 3);
>        end Tape_Client;

Re: [Q]: Distributed System Annex DSA

[Robert A Duff]

In article <32343D67.5E2D@ehs.ericsson.se>,
Jonas Nygren  <ehsjony@ehs.ericsson.se> wrote:
>I referred to the wrong package in my first question which
>made it self answering. Pls see below for correction.
>
>Jonas Nygren wrote:
>> 
>> For Gnat there now is a release of support for DSA. So I thought
>> it was time to get an understanding what DSA can do for me. I have
>> a few questions around this topic after trying to understand what
>> the Rational and the RM's texts on this feature. (If you can point me
>> to some more good educational text for DSA I would appreciate that.)
>> 
>> Now to my questions for which I use the example of Tape_Driver given
>> in Annex E of the RM. I attach the code from the RM at the end of
>> this posting.
>> 
>> 1)  When I studied this example I got the impression that the three
>>     parts Name_Server, Tape_Server and Tape_Client all could run
>>     in different partitions (and on different nodes). What confuses
>>     me is that the Name_Server does not have any 'pragma
>
>                      ^ ^  Ouch, it should have been Tape_Server

I see no Tape_Server in the code you quoted.  I assume you mean
Tape_Driver?  (Ouch again?  ;-))

>>     Remote_Call_Interface' and in the explaining text it is referred
>>     to as a 'normal package'. Does this imply that Tape_Client and
>>     Tape_Server must be co-located in the same partition? 

Tape_Driver and Tape_Client do not need to be in the same partition.

>...If not,
>>     how does the compiler know that Tape_Server's interfaces
>>     (Copy, Rewind) should be constructed to receive remote calls?

It doesn't need to.  Tape_Ptr is a remote access type, because of where
it's declared.  Normally, a pointer to a tagged type would be
represented as a pointer to the object.  The object contains a tag,
which is a pointer to the type descriptor, which contains pointers to
all the primitive operations.  But for a remote access type, the
compiler must do something different -- I think the best strategy is to
make the pointer point to a dummy object (on the same partition as the
pointer, of course).  Thus dummyy object has a tag, but instead of
pointing to the "real" type descriptor, it points to one which has
pointers to subprograms that send a message to the place where the
"real" object is located.  The "real" object, off on the other node,
doesn't need to know that it is being called remotely.

Make sense?

>> 2)  I have come to regard the package Tapes as the 'contract' of
>>     a tape service. Would this be the right place to enforce
>>     constraint and state checks to strengthen the consistency
>>     of the interface. State information would then be stored in
>>     the Tape (tagged) record. Are there any negative consequences
>>     in this approach and are there better ways to do this?

Sounds reasonable.

>> 3)  With CORBA and other similar technologies there is often much
>>     discussions on the need for threads in servers. My third question
>>     is about if and how one can use Ada tasks to achieve this in
>>     one remote active partition.
>> 
>>     One example in the Rationale showed how one could link together
>>     a number of active Worker partitions with a Controller partition
>>     and how these partitions could be distributed on different nodes.
>>     But nothing with tasks involved.
>> 
>>     My question is really if it is possible to multi-plex several
>>     service sessions on one partition. E.g. If Client A and B issues
>>     requests to the server 'at the same time' - how do I design the
>>     server so that these two calls can be overlapping and executed in
>>     parallel.

You can declare multiple tasks in a partition, as usual.

Also, the PCS is normally implemented with tasks, so that multiple
requests can be serviced simultaneously.

>> Any help appreciated!
>> 
>> Thanks in advance,
>> 
>> /jonas
>> 
>> -- Tape example from Ada RM e.4.2
>> 
>> (2)
>>        package Tapes is
>>           pragma Pure(Tapes);
>>           type Tape is abstract tagged limited private;
>>           -- Primitive dispatching operations where
>>           -- Tape is controlling operand
>>           procedure Copy (From, To : access Tape; Num_Recs : in Natural)
>> is abstract;
>>           procedure Rewind (T : access Tape) is abstract;
>>           -- More operations
>>        private
>>           type Tape is ...
>>        end Tapes;
>> (3)
>>        with Tapes;
>>        package Name_Server is
>>           pragma Remote_Call_Interface;
>>           -- Dynamic binding to remote operations is achieved
>>           -- using the access-to-limited-class-wide type Tape_Ptr
>>           type Tape_Ptr is access all Tapes.Tape'Class;
>>           -- The following statically bound remote operations
>>           -- allow for a name-server capability in this example
>>           function  Find     (Name : String) return Tape_Ptr;
>>           procedure Register (Name : in String; T : in Tape_Ptr);
>>           procedure Remove   (T : in Tape_Ptr);
>>           -- More operations
>>        end Name_Server;
>> (4)
>>        package Tape_Driver is
>>          -- Declarations are not shown, they are irrelevant here
>>        end Tape_Driver;
>> (5)
>>        with Tapes, Name_Server;
>>        package body Tape_Driver is
>>           type New_Tape is new Tapes.Tape with ...
>>           procedure Copy
>>            (From, To : access New_Tape; Num_Recs: in Natural) is
>>           begin
>>             . . .
>>           end Copy;
>>           procedure Rewind (T : access New_Tape) is
>>           begin
>>              . . .
>>           end Rewind;
>>           -- Objects remotely accessible through use
>>           -- of Name_Server operations
>>           Tape1, Tape2 : aliased New_Tape;
>>        begin
>>           Name_Server.Register ("NINE-TRACK",  Tape1'Access);
>>           Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
>>        end Tape_Driver;
>> (6)
>>        with Tapes, Name_Server;
>>        -- Tape_Driver is not needed and thus not mentioned in the
>> with_clause
>>        procedure Tape_Client is
>>           T1, T2 : Name_Server.Tape_Ptr;
>>        begin
>>           T1 := Name_Server.Find ("NINE-TRACK");
>>           T2 := Name_Server.Find ("SEVEN-TRACK");
>>           Tapes.Rewind (T1);
>>           Tapes.Rewind (T2);
>>           Tapes.Copy (T1, T2, 3);
>>        end Tape_Client;

- Bob

Re: [Q]: Distributed System Annex DSA

[Jonas Nygren]

Robert A Duff wrote:
> 
> In article <32343D67.5E2D@ehs.ericsson.se>,
> Jonas Nygren  <ehsjony@ehs.ericsson.se> wrote:
> >I referred to the wrong package in my first question which
> >made it self answering. Pls see below for correction.
> >
> >Jonas Nygren wrote:
> >>
> >> For Gnat there now is a release of support for DSA. So I thought
> >> it was time to get an understanding what DSA can do for me. I have
> >> a few questions around this topic after trying to understand what
> >> the Rational and the RM's texts on this feature. (If you can point me
> >> to some more good educational text for DSA I would appreciate that.)
> >>
> >> Now to my questions for which I use the example of Tape_Driver given
> >> in Annex E of the RM. I attach the code from the RM at the end of
> >> this posting.
> >>
> >> 1)  When I studied this example I got the impression that the three
> >>     parts Name_Server, Tape_Server and Tape_Client all could run
> >>     in different partitions (and on different nodes). What confuses
> >>     me is that the Name_Server does not have any 'pragma
> >
> >                      ^ ^  Ouch, it should have been Tape_Server
> 
> I see no Tape_Server in the code you quoted.  I assume you mean
> Tape_Driver?  (Ouch again?  ;-))

Yeah, I noticed my error just before leaving on a buisness trip and posted
my 'correction', in the taxi to the airport I got an uneasy feeling about
'Server' versus 'Driver', but since the taxi had no internet service I had 
no time to check up nor correct any errors a second time - then business class 
service made me forgetful.

> 
> >>     Remote_Call_Interface' and in the explaining text it is referred
> >>     to as a 'normal package'. Does this imply that Tape_Client and
> >>     Tape_Server must be co-located in the same partition?
> 
> Tape_Driver and Tape_Client do not need to be in the same partition.
> 
> >...If not,
> >>     how does the compiler know that Tape_Server's interfaces
> >>     (Copy, Rewind) should be constructed to receive remote calls?
> 
> It doesn't need to.  Tape_Ptr is a remote access type, because of where
> it's declared.  Normally, a pointer to a tagged type would be
> represented as a pointer to the object.  The object contains a tag,
> which is a pointer to the type descriptor, which contains pointers to
> all the primitive operations.  But for a remote access type, the
> compiler must do something different -- I think the best strategy is to
> make the pointer point to a dummy object (on the same partition as the
> pointer, of course).  Thus dummyy object has a tag, but instead of
> pointing to the "real" type descriptor, it points to one which has
> pointers to subprograms that send a message to the place where the
> "real" object is located.  The "real" object, off on the other node,
> doesn't need to know that it is being called remotely.
> 
> Make sense?

Yes. Almost like magic - perhaps the text should hav emphasized the 
importance of the 'remote pointer'. But: once told - never forget.

> 
> >> 2)  I have come to regard the package Tapes as the 'contract' of
> >>     a tape service. Would this be the right place to enforce
> >>     constraint and state checks to strengthen the consistency
> >>     of the interface. State information would then be stored in
> >>     the Tape (tagged) record. Are there any negative consequences
> >>     in this approach and are there better ways to do this?
> 
> Sounds reasonable.
> 
> >> 3)  With CORBA and other similar technologies there is often much
> >>     discussions on the need for threads in servers. My third question
> >>     is about if and how one can use Ada tasks to achieve this in
> >>     one remote active partition.
> >>
> >>     One example in the Rationale showed how one could link together
> >>     a number of active Worker partitions with a Controller partition
> >>     and how these partitions could be distributed on different nodes.
> >>     But nothing with tasks involved.
> >>
> >>     My question is really if it is possible to multi-plex several
> >>     service sessions on one partition. E.g. If Client A and B issues
> >>     requests to the server 'at the same time' - how do I design the
> >>     server so that these two calls can be overlapping and executed in
> >>     parallel.
> 
> You can declare multiple tasks in a partition, as usual.
> 
> Also, the PCS is normally implemented with tasks, so that multiple
> requests can be serviced simultaneously.

I dived into the Gnat DSA code and found in s-rpc.adb that a maximum of
127 anonymous tasks were created. Though, the stack size of these tasks
were fixed (~150 kb) and the configuration files (.cfg) did not seem to 
support a user defined stack size (well, 150 kb may seem enough in most cases
and also to much in other cases and finally to little in the odd case,
it would be nice if it was confgurable).

Though, DSA is really exciting. I believe it could provide the base for 
the 'killer' application Ada needs.

> 
> >> Any help appreciated!
> >>
> >> Thanks in advance,
> >>
> >> /jonas
> >>
> >> -- Tape example from Ada RM e.4.2
> >>
> >> (2)
> >>        package Tapes is
> >>           pragma Pure(Tapes);
> >>           type Tape is abstract tagged limited private;
> >>           -- Primitive dispatching operations where
> >>           -- Tape is controlling operand
> >>           procedure Copy (From, To : access Tape; Num_Recs : in Natural)
> >> is abstract;
> >>           procedure Rewind (T : access Tape) is abstract;
> >>           -- More operations
> >>        private
> >>           type Tape is ...
> >>        end Tapes;
> >> (3)
> >>        with Tapes;
> >>        package Name_Server is
> >>           pragma Remote_Call_Interface;
> >>           -- Dynamic binding to remote operations is achieved
> >>           -- using the access-to-limited-class-wide type Tape_Ptr
> >>           type Tape_Ptr is access all Tapes.Tape'Class;
> >>           -- The following statically bound remote operations
> >>           -- allow for a name-server capability in this example
> >>           function  Find     (Name : String) return Tape_Ptr;
> >>           procedure Register (Name : in String; T : in Tape_Ptr);
> >>           procedure Remove   (T : in Tape_Ptr);
> >>           -- More operations
> >>        end Name_Server;
> >> (4)
> >>        package Tape_Driver is
> >>          -- Declarations are not shown, they are irrelevant here
> >>        end Tape_Driver;
> >> (5)
> >>        with Tapes, Name_Server;
> >>        package body Tape_Driver is
> >>           type New_Tape is new Tapes.Tape with ...
> >>           procedure Copy
> >>            (From, To : access New_Tape; Num_Recs: in Natural) is
> >>           begin
> >>             . . .
> >>           end Copy;
> >>           procedure Rewind (T : access New_Tape) is
> >>           begin
> >>              . . .
> >>           end Rewind;
> >>           -- Objects remotely accessible through use
> >>           -- of Name_Server operations
> >>           Tape1, Tape2 : aliased New_Tape;
> >>        begin
> >>           Name_Server.Register ("NINE-TRACK",  Tape1'Access);
> >>           Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
> >>        end Tape_Driver;
> >> (6)
> >>        with Tapes, Name_Server;
> >>        -- Tape_Driver is not needed and thus not mentioned in the
> >> with_clause
> >>        procedure Tape_Client is
> >>           T1, T2 : Name_Server.Tape_Ptr;
> >>        begin
> >>           T1 := Name_Server.Find ("NINE-TRACK");
> >>           T2 := Name_Server.Find ("SEVEN-TRACK");
> >>           Tapes.Rewind (T1);
> >>           Tapes.Rewind (T2);
> >>           Tapes.Copy (T1, T2, 3);
> >>        end Tape_Client;
> 
> - Bob

Re: [Q]: Distributed System Annex DSA

[Robert A Duff]

In article <3237372C.50E6@joy.ericsson.se>,
Jonas Nygren  <jonas@joy.ericsson.se> wrote:
>Yeah, I noticed my error just before leaving on a buisness trip and posted
>my 'correction', in the taxi to the airport I got an uneasy feeling about
>'Server' versus 'Driver', but since the taxi had no internet service I had 
>no time to check up nor correct any errors a second time - then business class 
>service made me forgetful.

What's the world coming to, when you can't get decent internet service
in a taxi?

>Yes. Almost like magic - perhaps the text should hav emphasized the 
>importance of the 'remote pointer'. But: once told - never forget.

Any sufficiently advanced technogoy is indistinguishable from magic.
Who said that?  ;-)

Anyway, note that my description was just one possible implementation.
The best one, I think.  But another implementation is to make the access
values represented in some special way (maybe, fat pointers, containing
a node number plus an address within node).  It amounts to the same
thing -- the procedure being called doesn't need to know that it's being
called remotely, because some piece of software packages up the data
coming in, and unpackages the data coming out, and so forth.

>I dived into the Gnat DSA code and found in s-rpc.adb that a maximum of
>127 anonymous tasks were created. Though, the stack size of these tasks
>were fixed (~150 kb) and the configuration files (.cfg) did not seem to 
>support a user defined stack size (well, 150 kb may seem enough in most cases
>and also to much in other cases and finally to little in the odd case,
>it would be nice if it was confgurable).

You should keep in mind that the Ada RM envisions the *user* writing the
PCS.  The Ada compiler vendor doesn't (necessarily) provide it.

That doesn't mean that every Ada programmer needs to write his own.
The compiler vendor will usually provide one, and third parties might
provode one.  But keep in mind that you can write your own, or modify
the one you got from gnat dsa.

My point is, you can take that code and use a different max-tasks, and a
different task stack size, or whatever.  It's not exactly the same thing
as taking GNAT and modifying the compiler to recognize a different
language.  With free software, you can modify anything you want.  But
this is different -- a well-defined interace, and you can expect *any*
any compiler to provide this interface.

- Bob

Re: [Q]: Distributed System Annex DSA

[Philip Brashear]

In article <DxMxzv.GCx@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>Any sufficiently advanced technogoy is indistinguishable from magic.
>Who said that?  ;-)

I've always seen this quote attributed to Sir Arthur Clarke, science fiction
(and other) author, and one-time president of the British Interplanetary
Society.

(Except that he used the spelling "technology"  :-))   )

Phil Brashear

Re: [Q]: Distributed System Annex DSA

[Robert Dewar]

"Robert A Duff <bobduff@world.std.com> wrote:
>Any sufficiently advanced technogoy is indistinguishable from magic.
>Who said that?  ;-)"


I just read a Startrek novel where they got around the prime directive
and could use their modern technology because the society involved (based
on 14th century Germany) believed in magic and could accept the technology
as magic without causing culture clash :-)

Re: [Q]: Distributed System Annex DSA

[Robert Dewar]

Reposting article removed by rogue canceller.

"Robert A Duff <bobduff@world.std.com> wrote:
>Any sufficiently advanced technogoy is indistinguishable from magic.
>Who said that?  ;-)"


I just read a Startrek novel where they got around the prime directive
and could use their modern technology because the society involved (based
on 14th century Germany) believed in magic and could accept the technology
as magic without causing culture clash :-)

Re: [Q]: Distributed System Annex DSA

[Dale Stanbrough]

Any sufficiently advanced technogoy is indistinguishable from magic.


i've always liked the corollary...

	"Any technology distinguishable from magic is insufficiently advanced"
	
Dale :-)

Re: [Q]: Distributed System Annex DSA

[Samuel Tardieu]

>>>>> "Jonas" == Jonas Nygren <jonas@joy.ericsson.se> writes:

Jonas> I dived into the Gnat DSA code and found in s-rpc.adb that a
Jonas> maximum of 127 anonymous tasks were created. Though, the stack
Jonas> size of these tasks were fixed (~150 kb) and the configuration
Jonas> files (.cfg) did not seem to support a user defined stack size
Jonas> (well, 150 kb may seem enough in most cases and also to much in
Jonas> other cases and finally to little in the odd case, it would be
Jonas> nice if it was confgurable).

Jonas, your comments seem reasonable but you should really send this
kind of remarks to <distribution@act-europe.gnat.com> as well if you
want your suggestions to be discussed by the developpers and
maintainers.

Jonas> Though, DSA is really exciting. I believe it could provide the
Jonas> base for the 'killer' application Ada needs.

That's what we think too :)

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: [Q]: Distributed System Annex DSA

[Jon S Anthony]

In article <DxMxzv.GCx@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Any sufficiently advanced technogoy is indistinguishable from magic.
> Who said that?  ;-)

Clarke, A.C.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: [Q]: Distributed System Annex DSA

[Samuel Tardieu]

>>>>> "Jonas" == Jonas Nygren <ehsjony@ehs.ericsson.se> writes:

Jonas> Now to my questions for which I use the example of Tape_Driver
Jonas> given in Annex E of the RM. I attach the code from the RM at
Jonas> the end of this posting.

Jonas> 1) When I studied this example I got the impression that the
Jonas> three parts Name_Server, Tape_Server and Tape_Client all could
Jonas> run in different partitions (and on different nodes). What
Jonas> confuses me is that the Name_Server does not have any 'pragma
Jonas> Remote_Call_Interface' and in the explaining text it is
Jonas> referred to as a 'normal package'. Does this imply that
Jonas> Tape_Client and Tape_Server must be co-located in the same
Jonas> partition? If not, how does the compiler know that
Jonas> Tape_Server's interfaces (Copy, Rewind) should be constructed
Jonas> to receive remote calls?

Mmm... Seems like you wrote this in a hurry: the example you gave at
the end of your posting DO have a "pragma Remote_Call_Interface" just
after the "package Name_Server is" line. I suspect you are using an
old paper version of the RM and quoted it from the latest online
version. In the latest version, Name_Server is not referred to as a
'normal package': "Name_Server is a remote call interface package and
is elaborated in a separate active partition to provide the necessary
naming services ...", so your question is quite inappropriate :)

Jonas> 2) I have come to regard the package Tapes as the 'contract' of
Jonas> a tape service. Would this be the right place to enforce
Jonas> constraint and state checks to strengthen the consistency of
Jonas> the interface. State information would then be stored in the
Jonas> Tape (tagged) record. Are there any negative consequences in
Jonas> this approach and are there better ways to do this?

Since the Tape object itself won't migrate from one partition to the
other (all the primitive operations will be executed remotely), the
only overhead with extra check will be the one of the extra remote
calls needed, but this is IMHO the right approach.

Jonas> 3) With CORBA and other similar technologies there is often
Jonas> much discussions on the need for threads in servers. My third
Jonas> question is about if and how one can use Ada tasks to achieve
Jonas> this in one remote active partition.

If I understand your concern correctly, my answer is "don't worry
about this" (see below).

Jonas> One example in the Rationale showed how one could link together
Jonas> a number of active Worker partitions with a Controller
Jonas> partition and how these partitions could be distributed on
Jonas> different nodes. But nothing with tasks involved.

Jonas> My question is really if it is possible to multi-plex several
Jonas> service sessions on one partition. E.g. If Client A and B
Jonas> issues requests to the server 'at the same time' - how do I
Jonas> design the server so that these two calls can be overlapping
Jonas> and executed in parallel.

You don't have to do anything special: the requests will be handled
concurrently in two different tasks. The only thing you have to take
care of is synchronization if the remote procedures have to modify a
global object; in this case, you may need protected types.

Maybe you should try the DSA for GNAT 3.05; it's located at URL

     ftp://ftp.cs.nyu.edu/pub/gnat/dsa/dsa-1.0.tar.gz

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org