No timed entry calls on the client side or selective accepts on the server’s one? These look like the most obvious thing. Yet ARM E.2.3 (11.a/2) says:
We disallow the declaration of task and protected types, since calling an entry or a protected subprogram implicitly passes an object of a limited type (the target task or protected object). We disallow other limited types since we require that such types have available Read and Write attributes, but we certainly don’t want the Read and Write attributes themselves to involve remote calls (thereby defeating their purpose of marshalling the value for remote calls).
Which is nonsense, because the target task is remote and protected object is distributed. None of them needed to be streamed. A remote subprogram is limited too and never passed.
As for limited objects, they are limited and therefore shall be either distributed or remote. There should be an interface for distributed objects, e.g. synchronization calls on local handles or proxies. Ideally distributed objects should allow an implementation to move them across partitions e.g. tasks acting as wandering agents, cashing, voting and so on.
The problem was CORBA-like monolithic design of static partitions for closed upfront designed setups. It was reasonable 40 years ago. Distributed systems in these days are open with nodes coming and going, with components running on demand and switching not just cores but nodes, which is so even if you have something apparently monolithic as a car or a production line. [*]
So there is a huge and growing demand. Just look at the total garbage pile of modern communication protocols used for distribution: MQTT, ZeroMQ, ASN.1, AMQP, JSON+XML+ thousand other ML. They were designed because of that demand. They are popular and used just because there is no better choice in a weakly typed language, the languages dominating the world. Everything is a text now. Every packet is a message. Every exchange is an act of parsing and stripping off useless garbage from >1% content.
But with an Ada DSN you could just specify the things you want to share/distribute and forget about the rest, provided, we parted with the static/IDL mindset.
This is arguably what a distributed OS should do, but any OS development, meaning advancement, was killed by the ugly twins UNIX-Windows.
I used a bit of Ada DSA on a very small scale and a very long time ago. The performance was not very good and the interfaces felt a bit clunky. Most of my networking experience is based around C and Unix TCP and UDP sockets.
I agree with you about the inefficiency of the text protocols. I wrote an HTTP parser from scratch many years ago and found it quite tedious to parse various text tokens. Open standards like HTML, HTTP, SMTP, IMAP, etc. should have been designed as binary protocols, as these are much more efficient.
With regard to Ada DSA, I’m not sure I see any future there. It is probably better to design a framework (e.g. PVM, MPI, etc) and extend Ada distributed programming via packages. Ada tasking on shared memory systems many not map very well to distributed systems, so you probably need a completely different architecture. Ideally this would not rely on just TCP/IP but could be used with other type of interconnect like Infiniband and RDMA.
When they were designed, networks were slower and speed wasn’t an issue.
I’ve said before, it needs a complete redesign using aspects and allow complete replacement at the user level with those aspects. That way the compiler only has to adhere to an interface, everything is handled elsewhere.
How that will work within the runtime with tasks and parallel if DSA is removed
It is not just the network speed, but the effort required to implement a correct protocol parser and the amount of memory and CPU resources needed to parse plain text. It may be easier to write RFCs when describing text protocols, but for everything else, binary wins.
I get the point, but the language native constructs cannot cover everything in equal measure. So Ada tasking may work well for its original design, but distributed systems may have very different architectures and requirements. You either need to invent new language native constructs to allow for better flexibility or create new packages and libraries.
Aspects have a huge problem, they expose implementation. Either the language should provide deferred/private aspects (not sure about syntax, because “with private” is already in use, or a good old pragma is the way to go (one can move pragma into the private part).
First. It is not just tasking. In many applications shared objects are far more important. A typical sensor or actuator is just a variable you want read/write. Furthermore it is frequently a multicasting when the sensor is subscribed by many nodes. There are protocols beyond TCP for that, e.g. PGM (UDP is useless being unreliable and LAN only).
Second. I see nothing wrong with tasks except for lacking unconstrained return values and proper OO. Otherwise, there is nothing more at the interface level I could imagine. Same applies to protected objects. A protected action on a distributed object would be something totally different than a local protected action, but that is just an implementation detail for the user.
It depends on your needs and requirements. You can model existing Ada tasking via distributed systems, but you don’t really gain anything new. Distributed systems may have quite different capabilities, for example: distributed memory (memory segment split into chunks on Node-1, Node-2, Node-3, etc), task failover, retries and load-balancing, naming or directory services to identify specific tasks on a network, partitioning and isolation, node and cpu affinity may have very different semantics, etc. These may require completely new APIs and implementing a library package is much easier than changing core language constructs.
Yes, this is when you want to program it in C or Python. But in Ada you can go several storeys up and work with the language entities as if there were no physical distribution.
There is no need to change any language constructs. Object remains object, task remains task. There are certain properties of remote and distributed values, e.g. time stamp, QoS policy, validity/quality, historic values. These can easily be provided per user-defined attributes e.g.
Temperature'Timestamp
or per aspect/pragma
Air : constant Pressure := 0.0 -- Remote sensor
with Periodic => 0.01; -- QoS: poll each 10ms
On_Change; -- Keep the timestamp if unchanged
-- (within Pressure'Small)
Having packages is another advantage as you can describe the whole remote partition as a remote package with declarations inside being all automatically remote and bound in whatever way the implementation does it.
Of course one could go even more general and provide introspection for all objects, not just remote ones.
