Re: Standard library and distributed systems

[stt@houdini.camb.inmet.com (Tucker Taft)]

Andre Spiegel (spiegel@inf.fu-berlin.de) wrote:

: Last week I posted an article concerning distributability of types in
: Ada's standard library.  There were no replies, so here is a second
: try, hopefully a bit clearer.

: The problem: Ada.Strings.Bounded and Ada.Strings.Unbounded are not
: Remote_Types packages, which means that you cannot use bounded or
: unbounded strings for interpartition communications in a distributed
: system.  Since these types are very important, I find this a severe
: restriction for distributed programming in Ada, and I wonder whether
: this could be changed.
: ... 

I basically agree that we should endeavor to make all "interesting"
standard packages compatible either with pragma Pure or Remote_Types.
For Remote_Types, the package spec has to be preelaborable, and
any access types declared in the visible part of the package spec
are considered "remote" access types.  There are a number of restrictions
on the declaration and use of remote access types, and the 
Character_Mapping_Function in Ada.Strings.Maps and the String_Access
in Ada.Strings.Unbounded just don't cut it.

Rather than removing things from these packages (which could be very
disruptive to existing Ada 95 code), we could envision
additional pragmas or rules to make them "safe."    The simplest
would be to have a pragma Not_Remote_Type(type); which could
simply mark a given type that happens to be declared in a 
Remote_Types package as not being allowed as a formal parameter type
in a remotely callable subprogram.  For String_Access, an alternative
is to allow such a visible access type declaration to exist so long 
as there are 'Write and 'Read attributes specified that can safely 
transport such a value between partitions.  

For String_Access, it seems pretty obvious what 'Write/'Read would do,
namely have 'Write convert the access value into a stream representation 
of the designated string, and then have 'Read re-allocate the string in 
the heap on the receiving end.  Of course, this could end up as a 
horrible storage leak, so better might be to simply disallow String_Access
as a parameter type in remote calls.

In any case, I agree it would be nice to push Remote_Types further.
However, in the interim, using type String (or your own type) as the 
parameter type for a remote call, and doing the conversion to/from 
Unbounded_String manually does not seem excessively painful, since that 
is essentially what the 'Write/'Read for Unbounded_String must be doing 
anyway.

: Andre Spiegel
: Free University of Berlin

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA