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 15:19:18 +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="15855"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QubBAwWiBn3NEjVNVDdIJNBdiDjQ+ILM=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin) Cancel-Lock: sha1:YgFBc3MQb1MF4X9K91d5pr80hTk= sha1:ZWSziHfV8PjykogPAP1Shzk9pFw= Xref: reader01.eternal-september.org comp.lang.ada:55489 Date: 2019-02-11T15:19:18+00:00 List-Id: "Dmitry A. Kazakov" writes: > On 2019-02-11 14:35, Simon Wright wrote: >> "Dmitry A. Kazakov" 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.