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!feeder.eternal-september.org!aioe.org!.POSTED.fn3LatRFkm9/xzEj7F2/NQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada x Datagram Sockets Date: Mon, 11 Feb 2019 17:04:46 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <47f17695-f9a5-4024-b2da-3f13209dc4fd@googlegroups.com> <818f5ff4-f18d-42b8-950d-9b597c012aa4@googlegroups.com> <62406dfb-54c9-4db3-b461-0ad72d4a782c@googlegroups.com> NNTP-Posting-Host: fn3LatRFkm9/xzEj7F2/NQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:55490 Date: 2019-02-11T17:04:46+01:00 List-Id: On 2019-02-11 16:19, Simon Wright wrote: > "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. 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