Re: Asynchronous channels in Ada

[Hadrien Grasland <hadrien.grasland@gmail.com>]

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 implementations in the wild, which satisfy most of my requirements quite well.

However, I am a bit unsatisfied when it comes to the exception handling part of my requirements. Now, I am aware that this was the most exotic part (and 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 requirement. So let me elaborate on it further.

Let's put ourself in a typical usage scenario where you have a producer task and a consumer task, the former producing a stream of identically typed data 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 frontend.

Now, something goes wrong on the producer side, for any reason, which prevents this task from correctly producing its next data packet. Yet the consumer is expecting said packet. One can then imagine a number of options for the producer :

    Continue as if nothing happened and send the next packet, possibly logging 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 express error conditions, making option 4 pretty limited in practice. This only 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 perhaps some are thinking of using two FIFOs, one for regular data and one for exceptions. 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 inefficient 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 rare.

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 looks 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 when trying to read the corresponding data item.

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.

Just food for thought, I guess,
Hadrien