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!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Asynchronous channels in Ada Date: Mon, 22 Feb 2016 09:48:49 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: bqgfK7NL3xTHnr0WRaLl4g.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29584 Date: 2016-02-22T09:48:49+01:00 List-Id: On 21/02/2016 23:57, Hadrien Grasland wrote: > Now, something goes wrong on the producer side, for any reason, which > prevents this task from correctly producing its next data packet. That cannot happen. You should reconsider your design if you really think it could. When the communication channel is up the producer must function. I do not consider the case of a bug in the producer code. But anything else is just a valid state. That includes all handled exceptions on the producer side. And any valid producer state must have a corresponding valid state on the subscriber's side. This is just basics of any communication protocol design. > Transmit a specially crafted data packet representing an error (i.e. an exception). This is not an "error" it is a valid state. There is no problem to marshal an exception to the subscriber side. You make the data object like this: type Data (Abnormal : Boolean := False) is record case Abnormal is when True => Reason : Ada.Exceptions.Exception_ID; when False => ... -- Normal data end case; end record; Remove default value for Abnormal if your FIFO can handle indefinite objects. However, assuming that abnormal data objects are not frequently to transmit, making them indefinite might be not necessary. Regarding bugs, the safest way to handle a bug is to kill the application as early as possible. It makes debugging easier. > I wonder if I could find a way to build such a communication channel > and reuse existing FIFO implementations without incurring twice the > synchronization overhead. Most likely I should look into unsynchronized > FIFO implementations then. I think any implementation would go. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de