From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Ada x Datagram Sockets Date: Mon, 11 Feb 2019 13:35:07 +0000 Organization: A noiseless patient Spider Message-ID: References: <47f17695-f9a5-4024-b2da-3f13209dc4fd@googlegroups.com> <818f5ff4-f18d-42b8-950d-9b597c012aa4@googlegroups.com> <62406dfb-54c9-4db3-b461-0ad72d4a782c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="553b2f89afe391c26b2f2b049e5455b6"; logging-data="4764"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/u0W5fFsqbfdRIA71ajPfEGnpq/c22cgw=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin) Cancel-Lock: sha1:GGSnbAbwufNnaH4qwKKNKoPShfk= sha1:YMQyMWZuwDo1tKrvlW1/n+z9zSY= Xref: reader01.eternal-september.org comp.lang.ada:55487 Date: 2019-02-11T13:35:07+00:00 List-Id: "Dmitry A. Kazakov" writes: > On 2019-02-10 18:54, Simon Wright wrote: > >> A further benefit of using streams was that we were communicating >> between machines of different endianness, and GNAT contains an >> optional stream implementation that will transparently convert >> to/from network byte order. > > That does not make much sense. Most protocols of the layers above > simply ignore that and use the order (encoding, actually) they prefer > for whatever reason. Furthermore encoding integers is the least > problem. Machine A (a PowerPC) will automatically send the contents of a record in network byte order. Machine B (x86_84) will handle the protocol without problem but requires the content of the the record to be converted to host byte order. Best, especially if the record content is subject to change, if that conversion can be automatic. 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. > 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).