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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Asynchronous channels in Ada Date: Mon, 22 Feb 2016 10:28:03 +0100 Organization: A noiseless patient Spider Message-ID: References: Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 22 Feb 2016 09:24:41 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="1725"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18p9CcijTjQq23Yy1K0aF/742unzWjiDjs=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: Cancel-Lock: sha1:HbrzV85QNL9KKxjI4APcFNMTNb4= Xref: news.eternal-september.org comp.lang.ada:29585 Date: 2016-02-22T10:28:03+01:00 List-Id: On 21.02.16 23:57, Hadrien Grasland wrote: > Transmit a specially crafted data packet representing an error (i.e. an exception). Just for clarification, this sounds like a representation of a value that expresses "error", so in the strict Ada sense it would not be an exception, and so cannot trigger anything that isn't expressly looking for an error value and then raises (like in Dmitry's solution that uses an exception identifier as a "normal" value; in extension, I'd consider an abstract common type from which two concrete types are derived, one for good state and one for bad state, if you want to separate concerns accordingly and avoid repeated conditionals inspecting discriminant values). But I'm assuming you want some mechanism that is triggered automatically so that coding the normal case does not need to perform case distinctions? At this point, I'd also look into locating the errors, in the sender, in the enqueuing call, during processing, during delivery, again during processing, in the dequeuing call, and in validating steps. Maybe, then, there is need for more than a Boolean indicator, like an enumeration that's known to all parties, or more wrapper types one for each of the locations, etc. One thing that comes to mind is a notification system like interrupts: A wants B to know that there was an exception, so A signals (by intent) B so as to interrupt it, or A has some other special task N deliver a notification, which again interrupts B. Or N is a high priority caller or some such, but there is that would be case distinction again (by task entry). Another option that might work is alternating inspection of a data queue a second queue that sends state information as necessary. -- "HOTDOGS ARE NOT BOOKMARKS" Springfield Elementary teaching staff