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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.29.41 with SMTP id g9mr24645268obh.27.1456095456496; Sun, 21 Feb 2016 14:57:36 -0800 (PST) X-Received: by 10.182.112.202 with SMTP id is10mr293075obb.7.1456095456472; Sun, 21 Feb 2016 14:57:36 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!hb3no8029035igb.0!news-out.google.com!l1ni20889igd.0!nntp.google.com!ok5no4255667igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 21 Feb 2016 14:57:36 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=78.192.88.225; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 78.192.88.225 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Asynchronous channels in Ada From: Hadrien Grasland Injection-Date: Sun, 21 Feb 2016 22:57:36 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29581 Date: 2016-02-21T14:57:36-08:00 List-Id: Hi all, Thank you for your numerous and insightful replies ! As of now, I'm pretty = convinced that I can easily find many excellent synchronized FIFO queues im= plementations in the wild, which satisfy most of my requirements quite well= . However, I am a bit unsatisfied when it comes to the exception handling par= t of my requirements. Now, I am aware that this was the most exotic part (a= nd go's channels, which I take inspiration from, don't take care of that at= all). I also noticed that Dmitry sounded quite confused by that requiremen= t. So let me elaborate on it further. Let's put ourself in a typical usage scenario where you have a producer tas= k and a consumer task, the former producing a stream of identically typed d= ata that is read by the other. This producer/consumer pair may be part of a= fairly large and complex data processing pipeline, such as a compiler fron= tend. Now, something goes wrong on the producer side, for any reason, which preve= nts this task from correctly producing its next data packet. Yet the consum= er is expecting said packet. One can then imagine a number of options for t= he producer : Continue as if nothing happened and send the next packet, possibly logg= ing the error somewhere. Abort the whole program. Ask the user what to do. Emit a regular data packet with a special value (e.g. NaN for a float). Transmit a specially crafted data packet representing an error (i.e. an= exception). Option 1 is usually too little, and option 2 is usually too much. Option 3 = is a cop-out with terrible usability. Most data types are not designed to e= xpress error conditions, making option 4 pretty limited in practice. This o= nly leaves option 5 of designing either data transmission channels or their= contents with error handling in mind. Now, you can't do that very well with a simple FIFO, because that container= is only designed as a transmission channel for one type of data. So perhap= s some are thinking of using two FIFOs, one for regular data and one for ex= ceptions. But then, the consumer will need to check for exceptions all the = time, in addition to regular data, a design which is both error-prone (for = the developer) and inefficient (twice the synchronization overhead). Another option is to use one FIFO, but have it carry not just regular data = but a wrapper type which can take either data or exceptions. That design is= also quite impractical for the consumer, and it is also somewhat inefficie= nt since all data packets need to carry an extra discriminant which must be= written by the producer and analyzed by the consumer, even if errors are r= are. My conclusion is that the optimal solution would be something slightly more= advanced than a FIFO, which basically encapsulates together a regular FIFO= and a simpler exception transmission mechanism (maybe just a boolean flag = and a one-element buffer). For all intents and purpose, the resulting ADT l= ooks and feel mostly like a FIFO to everyone involved. But the producer can= also send exceptions through it, in which case the consumer will throw whe= n trying to read the corresponding data item. I wonder if I could find a way to build such a communication channel and re= use existing FIFO implementations without incurring twice the synchronizati= on overhead. Most likely I should look into unsynchronized FIFO implementat= ions then. Just food for thought, I guess, Hadrien