Re: Ada x <whatever> Datagram Sockets

[Simon Wright <simon@pushface.org>]

"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.

>>> 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.