Sorry for the delayed reaction cdimauro. I simply lost track of your message.
np. I also reply when I can: we all have a real life.
As deadw00d wrote, each and every AROS program (when started with axrt) uses its own (linux) address space. As such the ipc requires to follow the linux guideline with regards to IPC.
However Linux has several IPC mechanisms. AFAIR there are 6 that can be used (depending on the specific needs).
I don't now the IPC implementation that you talked about, but I assume that it's a form of message passing, mapping those messages to the various processes' virtual memory spaces (not necessarily on the same virtual addresses), and probably some sort of marshalling (otherwise it's difficult to see how your mentioned languages can communicate, since they are very different).
Let's make it a bit more practical then. It is just a (simple) example, but please have a look here (https://wiki.lazarus.freepascal.org/SimpleIPC_Library). If i remembered correctly then you did not seem shy of a bit of Pascal code, so please do follow the github link and take a look at the code.
Thanks, and you're right: before Python it was Pascal/Delphi my beloved programming language.
In the end it is just a generic library and simply offers a generic API that can be used for every platform/programming language. You can make such thing as complicated and/or simple as one wish it to be.
Basically it does what I was suspecting. In fact, it gives a basic layer for establishing a communication (client / server) with a few API for sending some common data types (int32, string), but nothing else.
In fact, for more complex data types, you need to choose some marshaling. They suggest Google Protocol Buffer:
"More advanced IPC: google protocol buffers in combination with simpleipc means you can send standardized data using the well known google protocol buffer mechanism (GPB). The GPB does not handle IPC for you, so when you need IPC mechanism to actually send and receive the google protocol buffer, why not use SimpleIPC?"The good thing of that library is that it's simple: it exposes some basic APIs for establishing a communication between two processes and sending/receiving data.
The bad thing is that they tried to offer some APIs for exchanging data, but they cover only a bunch of common data types, and use to convert to string everyting, unfortunately, which is quite inefficient.
What's even worse, is that they sell this library as it makes easier to exchange messages using any datatype. As a pythonist, I can say that to achieve it you need a super-complex marshaling protocol that it's very very difficult to implement on languages other than Python.
I give you a basic example: integers. In Python integers have "unlimited" size: you can store very big numbers which are only limited by your memory. Whilst it's very easy for Python to marshal them to some format (classic conversion to string, for example, which is not that efficient but... effective: easy to understand, at least), how other languages will cope with that?
And this is a very basic example. Python offers a broad range of datatypes, both as built-in and in its standard library, and many of them can be freely combined. You can imagine how complex a data can become in Python. And how super difficult would be to find a way to marshal it AND be handled by different programming languages.
So, in short: the library is good for very basic message passing, but fails (and I'm polite here) on its claimed goals of being of general use.
However marshalling means also slow, especially if you want to pass complex structures. It also means that the existing Amiga applications require could requite notable changes to use this new mechanism.
For sure it is/can be. But how do modern programs use IPC ? Take note that there are several programs that even do this kind of things using networked connections (either local, lan or wan) and that there are several protocols each and everyone with their own individual pros and cons.
Indeed. And that's why the library is failing: it doesn't even give a protocol generic-enough for the more common needs. You have either to reinvent the wheel (new protocol) or use another protocol for marshaling the data.
Problem NOT solved...
In the specific instance that i've made my remark i was more thinking along the line of being compliant (from a outside point of view) rather then suggesting each and every program that wants IPC should make use of it.
Unfortunately it's not easy to use the library as it is: too much limited, and requires extra effort and/or external libraries for mashalling more complex data.
As you pointed out perfectly, Amiga OS has it's own proofed and tested implementation(s) that for sure will have more pros than cons.
The only other way i am able to see a implementation that might be a better solution (but would require more work) is a complete implemented VM for the axrt, so that the vm can decide what each individual axrt process is allowed/disallowed to do. So there would have to be provisions (read extra layer inside the vm) for that.
Yes. But AxRT then needs to know which applications can communicate in some way (Amiga o.s., SimpleIPC...)
But perhaps you have another and/or better idea ?
As a developer, I prefer to have a more general solution which works out-of-the-box for the most common cases.
SimpleIPC isn't good for the above reasons. It would have been better for this library to offer only a single, basic, API for sending and receiving a sequence of bytes.
So, leaving the data types marshalling to something else (GPB, JSON, YAML, XML, ...).
But offering the marshalling as already built-in.
