Version 1.5 of ais/ai-00273.txt

Unformatted version of ais/ai-00273.txt version 1.5
Other versions for file ais/ai-00273.txt

!standard E.05 (01)          02-02-08 AI95-00273/01
!class amendment 01-09-05
!status ARG Approved 7-0-0 02-02-10
!status work item 02-02-08
!status received 01-08-23
!qualifier Error
!priority Low
!difficulty Hard
!subject Use of PCS should not be normative
!summary
Implementations are not required to support the interface of the language-defined package System.RPC. Implementations are permitted to support alternative versions of the package System.RPC for implementing remote subprogram calls.
!question
System.RPC is designed to allow users to change from one vendor PCS to another. System.RPC is well suited for the possible implementation mentioned in E.4(20). But this specification makes strong assumptions on the implementation and other implementations become almost impossible. For instance, AARM E.4(20d) suggests that partition ids are statically defined. Therefore, System.RPC.Partition_Id has no specific primitives. A more dynamic implementation of DSA would probably provide an additional library unit as part of the PCS in order to deal with partition ids. But the user is no longer able to change of PCS.
By removing this rule, compiler vendors would be allowed to delegate the implementation of DSA (or at least the PCS implementation) to other vendors like CORBA vendors. This would also allow DSA to interoperate with other distribution models like CORBA (no longer Ada talking to Ada).
!recommendation
Implementations are not required to support the predefined interface of System.RPC if another interface is more appropriate for the communication subsystem. Implementations are allowed to provide an alternative version of package System.RPC, however they should be encouraged to support a substantially equivalent set of capabilities to that defined in the predefined specification of the package.
!wording
Delete the normative sentence at the end of E.5(1) that requires using the language-defined System.RPC interface.
Under implementation advice, add:
An alternative declaration is allowed for package System.RPC as long as it provides a set of operations that is substantially equivalent to the specfication defined in this clause.
!discussion
The current language requires implementors of Annex E to support the interface to the PCS defined in E.5 (package System.RPC). The original concept of requiring this standardization was to allow for a well-defined interface separating the compiler support for marshalling and unmarshalling from the implementation of the underlying communication subsystem, which might well be provided by another vendor. The idea was that such a separation would enhance portability of PCS implementations by providing a "plug and play" capability.
As it has turned out in practice, Annex E has not been widely implemented by vendors. In fact, at the time of this writing, only one vendor has chosen to provide full support for the Annex. This vendor has discovered that the existing definition of System.RPC is overly constrained for supporting distributed environments such as CORBA, which provide a richer set of capabilities than that afforded by the predefined RPC interface. Although the language allows extending the set of operations of System.RPC and the definition of child units, it still imposes a model based on a particular notion of Partition_Ids and send-receive operations that may limit its applicability.
It's unreasonable to constrain implementations to support an interface that is deemed unsuitable or overly inflexible for their target distribution environments. In particular, it doesn't make sense to require vendors to support the predefined interface along with other interfaces only for the purpose of satisfying a reference manual requirement if their target users do not benefit from its support. An analogy can be made with the run-time support for tasking implementations, where it would be unreasonable for the language to attempt to define a particular interface to tasking primitives, since this would be unlikely to provide a suitable and efficient mapping to a wide variety of underlying tasking executives.
Consequently this AI removes the normative rule requiring support for the language-defined interface for System.RPC and changes this to Implementation Advice. Note that the flexibility provided by relaxing this requirement is similar to what is allowed for package Ada.Command_Line, where implementations are permitted to change the interface to suit the particulars of argument passing on a given operating system. Given that System.RPC is not a user-level interface it seems even more appropriate to permit vendors to have this kind of flexibility in changing the interface of System.RPC and not to be burdened with supporting an interface that may be inappropriate or inadequate for the distributed communication protocols available on their chosen environments.
!corrigendum xx.xx(xx)
Replace the paragraph:
The Partition Communication Subsystem (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS. An implementation conforming to this Annex shall use the RPC interface to implement remote subprogram calls.
by:
The Partition Communication Subsystem (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS.
Insert after the paragraph:
The Write operation on a stream of type Params_Stream_Type should raise Storage_Error if it runs out of space trying to write the Item into the stream.
the new paragraph:
An alternative declaration is allowed for package System.RPC as long as it provides a set of operations that is substantially equivalent to the specfication defined in this clause.
!ACATS test
Several existing ACATS tests will have to be deleted if this AI is approved.
!appendix

!topic use of PCS should not be normative
!reference RM95-E.5(1)
!from Laurent Pautet 01-08-23
!keywords Annex-E, PCS, System.RPC
!discussion

1/ System.RPC is designed to allow users to change from one vendor PCS
to another. System.RPC is well suited for the possible implementation
mentioned in AARM E.4(20). But this specification makes strong
assumptions on the implementation and other implementations become
almost impossible. For instance, E.4(20d) suggests that partition ids
are statically defined. Therefore, System.RPC.Partition_Id has no
specific primitives. A more dynamic implementation of DSA would
probably provide an additional library unit as part of the PCS in
order to deal with partition ids. But the user is no longer able to
change of PCS.

2/ There is no such rule in the rest of the language. For instance, it
would probably be dramatic to force a tasking implementation to use a
given API. A direct consequence of this rule is that it is very
difficult (and almost impossible) to port DSA on the top of a CORBA
ORB without violating E.5(1). As suggested in the possible
implementation E.4(20), a distributed entity is described by a
partition id and a RPC-receiver defined in System.RPC. Therefore, it
is very difficult to represent a distributed entity as an IOR. Note
also that CORBA does not normalize things at the level of ORB
interface but at the level of stub and skeleton interface and at the
protocol level.

3/ By removing this rule, the revision team would allow compiler
vendors to delegate the implementation of DSA (or at least the PCS
implementation) to other vendors like CORBA vendors. Using System.RPC
has too much impact of the communication system architecture. This
would also allow DSA to interoperate with other distribution models
like CORBA (no longer Ada talking to Ada). More generally, this would
encourage DSA implementations (rather than constraining it), open this
annex to other technologies like CORBA and increase its use and
interest.

****************************************************************

From: Robert Duff
Sent: Sunday, August 26, 2001 4:03 PM

!topic use of PCS should not be normative
!reference RM95-E.5(1)
!reference Laurent Pautet 01-08-23
!from Bob Duff
!keywords Annex-E, PCS, System.RPC
!discussion

> 2/ There is no such rule in the rest of the language. For instance, it
> would probably be dramatic to force a tasking implementation to use a
> given API.

I won't comment (yet?) on the rest, but I'll just point out that there
*is* precedent for this sort of rule: the stuff about user-defined
storage pools in chap 13 is like that.  The compiler has to be prepared
to redirect "new" and Unchecked_Deallocation to the user-defined
operations.  Likewise, in Annex E, the compiler has to be prepared to
redirect networking operations to user-defined code.

****************************************************************

From: Laurent Pautet
Sent: Monday, August 27, 2001 9:02 AM

Right. Another example would be stream attributes. But you should
compare features of same magnitude. You cannot compare malloc/free
with all the socket primitives. The job to get a working network
programming interface is more difficult than to get a memory
allocation interface. To be fair, compare with tasking. And it is
still not really fair because I guess that in the Ada community,
people are more familiar with real-time systems than with non-realtime
distributed systems.

The intention for storage pools and stream attributes is to make user
code portable between compilers. For DSA, it is to make code generated
by compilers portable between PCS implementations. The first intention
was to allow compiler vendors to delegate the PCS implementation to
some other vendors and not to the user !

Let's assume that the second intention was to allow user to provide a
PCS implementation. It can explain why System.RPC is so simple. But to
get back to the tasking example, how many users develop their own
run-time compared to those that develop their own storage pools ? And
if they develop their own run-time, do you agree that they have better
to work very tighly with the compiler vendor ? For the same reason,
very few users will develop their PCS. For the same reason, if they
do, they will interact with their compiler vendor very tighly.

System.RPC was defined 8 years ago without any implementation
available to validate this interface. If you look at other
distribution model, it is clear that for instance, DSA is missing a
naming service like COSNaming in CORBA. System.RPC was specified with
the static design described in the AARM in mind. Is it reasonable to
keep working with such an API for Ada0X ? Distributed systems is a
domain in which Ada should expand and not be constrained.

****************************************************************

From: Pascal Leroy
Sent: Monday, August 27, 2001 2:55 AM

> 3/ By removing this rule, the revision team would allow compiler
> vendors to delegate the implementation of DSA (or at least the PCS
> implementation) to other vendors like CORBA vendors.

An implementation may provide a (configuration?) pragma Do_Not_Use_PCS in
order to short-circuit the PCS and use whatever communication subsystem it
likes.  This is perfectly legal, and much easier/faster than changing the
language.  Moreover, considering the number of implementations which support
annex E, I don't think the portability problems would be too bad...

****************************************************************

From: Robert Dewar
Sent: Monday, August 27, 2001 4:48 AM

<<An implementation may provide a (configuration?) pragma Do_Not_Use_PCS in
order to short-circuit the PCS and use whatever communication subsystem it
likes.  This is perfectly legal, and much easier/faster than changing the
language.  Moreover, considering the number of implementations which support
annex E, I don't think the portability problems would be too bad...>>

Obviously this response is more than adequate for current Ada 95 compilers.
I think the comment was more about the future revision of Ada. The question
is whether the current view of plug-and-play PCS makes sense to continue
in the new version, given its total lack of success for Ada 95. Yes, at
least we have one complete implementation of Annex E, and it is being used
successfully, but the notion of a standard interface for the PCS turns out
to be completely irrelevant, and, as pointed out by this comment, actively
unhelpful.

****************************************************************

From: Robert Duff
Sent: Monday, August 27, 2001 3:24 PM

Does this mean that the plug-and-play PCS idea is hopeless?
Or does it merely mean that this particular interface
is the wrong interface?

****************************************************************

From: Randy Brukardt
Sent: Tuesday, August 28, 2001 7:09 PM

> System.RPC was defined 8 years ago without any implementation
> available to validate this interface. If you look at other
> distribution model, it is clear that for instance, DSA is missing a
> naming service like COSNaming in CORBA. System.RPC was specified with
> the static design described in the AARM in mind. Is it reasonable to
> keep working with such an API for Ada0X ? Distributed systems is a
> domain in which Ada should expand and not be constrained.

The problem here is that Annex E was designed for a homogeneous distributed
system written completely in Ada, while the sort of systems that you are
envisioning are hetrogeneous distributed systems written in a variety of
languages. I would expect that Annex E would need a lot more changes than to
just the PCS to work in such an environment. I don't think a piecemeal
approach to revising the annex will buy much, and any revision to the annex
will eat up a lot of valuable time. (I'd rather spend the time on a standard
Sockets library - a lot more users would benefit.)

The big question is whether enough users are interested in a revision of
Annex E to justify the work. If we base that on the existing users and
implementations, the answer would appear to be no. So I think anyone wanting
to revise Annex E would need to show an constituency and probably some
volunteers to work on the proposals.

****************************************************************

From: Robert Dewar
Sent: Tuesday, August 28, 2001 9:09 PM

<<The problem here is that Annex E was designed for a homogeneous distributed
system written completely in Ada, while the sort of systems that you are
envisioning are hetrogeneous distributed systems written in a variety of
languages. I would expect that Annex E would need a lot more changes than to
just the PCS to work in such an environment. I don't think a piecemeal
approach to revising the annex will buy much, and any revision to the annex
will eat up a lot of valuable time. (I'd rather spend the time on a standard
Sockets library - a lot more users would benefit.)>>

The answer is that a major effort has been put into studying this issue,
and the answer is well understood to be that Annex E can most certainly be
implemented in such environments without any language changes, except that
the PCS interface is not relevant or implementable.

Note that the fact that Annex E was designed for homogenous distributed
systems, but the GNAT implementation has always fully supported
heterogenous distribution using XDR, and several of our GLADE customers
are using Annex E in a heterogenous environment.

<<The big question is whether enough users are interested in a revision of
Annex E to justify the work. If we base that on the existing users and
implementations, the answer would appear to be no. So I think anyone wanting
to revise Annex E would need to show an constituency and probably some
volunteers to work on the proposals.>>

Nobody is asking for such a revision. The only people who are interested
in implementing this are telling you that the only thing that is needed to
make the implementation practical is to relax the PCS interface requirement.
It is not practical for GNAT to implement two quite separate PCS interfaces,
so this becomes a crucial issue.

So please do not waste any of your (or anyone else's) time "revising"
Annex E, such work is of no interest to those who have actually invested
(and are interested in continuing to invest) major effort in Annex E
implementation.

The one and only issue here is that it would be helpful to revise the
language at this stage to make the use of the PCS interface described
in the RM to be implementation advice rather than a requirement. That
seems to me a very small step, and one that will enable continued valuable
work to be done in this area.

****************************************************************

From: Tucker Taft
Sent: Tuesday, August 28, 2001 8:39 PM

Laurent Pautet wrote:
> ...
>
> The intention for storage pools and stream attributes is to make user
> code portable between compilers. For DSA, it is to make code generated
> by compilers portable between PCS implementations. The first intention
> was to allow compiler vendors to delegate the PCS implementation to
> some other vendors and not to the user !

The original intent was to delegate the PCS implementation to
the (sophisticated) user.  This was based on the presumption that
the average compiler writer knows less about networking than
the average builder of a distributed system.  I still believe
that is true.  It can be argued that one of the initial problems
with Ada 83 was that compiler vendors were expected to build
real-time executives, when many of them had no clue how to
do so.  Now we see a large percentage of Ada systems being
built on top of commercial RT executives, but that wasn't
true in Ada 83.  Every vendor felt it necessary to build a
RT executive from scratch.  To be fair, in 1983, there weren't
many commerical RT execs around.

In any case, we wanted to avoid creating the same situation, where
compiler vendors would produce lousy implementations of the PCS
and thereby interfere with high-performance distributed Ada
applications.  Clearly the compiler had to do marshalling and
unmarshalling, but there seemed no reason why the compiler vendor
had to be involved directly with the actual partition-to-partition
communication process, especially given the number of bizarre
buses that are used for interconnecting CPUs.  It may be that
sockets have become so ubiquitous that effectively the same thing
is accomplished by allowing a user to supply their own TCP/IP stack,
but I have to believe that plenty of distributed systems don't want
the full overhead of TCP/IP.

So that was our intent.  I can believe we screwed up the PCS
interface in various ways, but I still think the idea is reasonable,
and perhaps a better PCS could be defined.  Whether it is worth
it at this point I don't know.  Certainly we should allow vendors
to bypass the PCS (we do), and since there is only one compiler vendor
that supports annex E (as far as I know), there seems little burden
in requiring them to continue to support the PCS interface.

****************************************************************

From: Robert Dewar
Sent: Wednesday, August 29, 2001 4:57 PM

<<So that was our intent.  I can believe we screwed up the PCS
interface in various ways, but I still think the idea is reasonable,
and perhaps a better PCS could be defined.  Whether it is worth
it at this point I don't know.  Certainly we should allow vendors
to bypass the PCS (we do), and since there is only one compiler vendor
that supports annex E (as far as I know), there seems little burden
in requiring them to continue to support the PCS interface.>>

Well the consequence of "requiring them to continue to support the PCS
interface" is that we will likely abandon Annex E as the basis for
distribution over e.g. CORBA, since it is impractical for us to maintain
two separate PCS interfaces in the compiler. That's too bad, but we tried :-)

We don't really allow vendors to bypass the PCS if the validation tests (three
rather miserable tests) require the PCS to be implemented as described in the
RM.

****************************************************************

From: Pascal Leroy
Sent: Thursday, August 30, 2001 3:58 AM

Robert proposed:

> The one and only issue here is that it would be helpful to revise the
> language at this stage to make the use of the PCS interface described
> in the RM to be implementation advice rather than a requirement. That
> seems to me a very small step, and one that will enable continued valuable
> work to be done in this area.

That seems like a reasonable idea to me, as it doesn't have any negative
impact, and it enables implementations to support more sophisticated
distribution models. Moreover, if some customers really want the original
PCS, well, they'll tell Robert.

Tuck replied:

> I can believe we screwed up the PCS
> interface in various ways, but I still think the idea is reasonable,
> and perhaps a better PCS could be defined.  Whether it is worth
> it at this point I don't know.

I'd say that it's a good thing to look into once Tuck has completed all of his
other outstanding action items (hint).  I'm unwilling to spend any ARG time on
this, if only because we have very little expertise in this area.  Of course we
can invite the GNAT implementers, but since they are the only ones who
understand the issues, we might as well give them carte blanche by making the
PCS an implementation advice.

> ... since there is only one compiler vendor
> that supports annex E (as far as I know), there seems little burden
> in requiring them to continue to support the PCS interface.

I think I heard Robert say the opposite.  I can imagine that having to support
two interfaces can be a significant maintenance burden, and if one of them is
unused, why bother?

****************************************************************

From: Nick Roberts
Date: Tuesday, October 30, 2001  4:55 PM

(Forwarded by Tucker Taft)

If not fresh in your mind, this AI is about the fact that the PCS defined in
the RM95 is really only suitable for a distributed system composed of a
static set of Ada 95 partitions, and is (almost) unusable for more dynamic
or interoperative types of distributed system.

The suggestion is to make the whole PCS mechanism optional in the next
revision, largely on the grounds that the reviewers do not have time to
develop the PCS idea to the extent it would have to be to fulfil the wider,
more flexible, requirements.

I believe that there would be great value in a new and (significantly)
improved PCS (standard, language-defined) definition, and that it could and
should be developed. I would be willing to devote the time necessary to
develop my own detailed suggestion for this, if it would be of any interest
to you.

The next revision could specify both the current PCS solution (System.RPC)
and the new one (perhaps System.Advanced_RPC), and permit an implementation
(conforming to the annex) to use either one, or to provide a choice of
either (or neither), via a configuration pragma:

pragma Partition_Communication_Subsystem(Normal|Advanced|Native);

The 'Native' option would provide for an implementation that bypasses either
of the standard PCSs.

I also feel that the standard should define a naming service (like CORBA's
COSNaming). I have already worked to some extent on a naming service for
AdaOS; this could be readily adapted.

Needless to say, this is an issue that could have great significance for
AdaOS.

I don't (readily) have the e-mail addresses of the other reviewers of this
AI (Laurent Pautet, Bob Duff, Pascal Leroy, Robert Dewar, and Randy
Brukardt), and I'm not too sure of the correct protocol or procedure in this
situation, so I hope you don't mind me e-mailing you this way. I'd be
grateful if you could steer me onto the right path (if there is one).

****************************************************************

From: Robert Dewar
Date: Thursday, November 8, 2001  9:42 PM

I think it is pointless to do this work on a PCS at the ARG level. There is
no point in mandating things at this stage, when only one vendor has shown
any interest in doing Annex E at all. I think it would make more sense for
Nick to do an experimental implementation with GNAT.

****************************************************************


Questions? Ask the ACAA Technical Agent