Re: Ada x <whatever> Datagram Sockets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2019-02-11 16:19, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 2019-02-11 14:35, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> On 2019-02-10 18:54, Simon Wright wrote:
> 
>>> A consideration on that project was that the target hardware was all
>>> PowerPC, and conversion load was to be avoided if possible, while the
>>> x86_64 part was all about logging and analysis, and had cycles to
>>> spare.
>>
>> There is no conversion at all. You simply encode a packet and decode
>> it. That is it. Ada's machine representation of the types in the
>> application plays no role.
> 
> You say encode/decode, in the case I'm talking about it seemed to me
> that conversion was an equally valid way of stating it. And, just in
> case it's not clear, the Ada types in the application were of primary
> importance.

I only say that in practice it is a very rare case. Even if your 
objective is to simply communicate between two piers, you would end up 
rather with some standardised protocol instead of sending custom records 
around. The problem with the latter is maintaining states on the both 
sides and error recovery. Beyond some very simple cases records would 
not scale/work.

>>>> Anyway, there are two major and quite different cases: piped I/O
>>>> vs. encoding/decoding. You refer to the latter and FIFO is likely the
>>>> former.
>>>
>>> If you're communicating within one program, use an indefinite
>>> queue. If between two programs, I don't see there's a lot of
>>> difference really (OK, if the programs are both on x86_64, doesn't
>>> make much sense to convert the contents to network byte order! which
>>> is a disadvantage of using a modified runtime, of course).
>>
>> Stream is not queue unless you mean a queue of stream elements. I
>> suppose that using a queue of stream elements will inflict too much
>> overhead if you put a stream interface on top of it to be usable.
> 
> Within one program, why use streams at all? Just have an indefinite
> queue of objects.

The use case is when a component is designed to work with an external 
file. Quite frequently one wishes to replace file I/O with a general 
provider/consumer interface. Ada stream is a convenient common denominator.

Queue of [indefinite] typed objects is a higher-level and better 
abstraction. It would work, and would be safer too, if we had an 
object-based OS and persistency layer instead of files, all written in 
Ada. Unfortunately we do not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de