Idea: use LinkedBlockingQueues instead of core.async channels

[daveyarwood]

The Alda parser implementation is asynchronous, using clojure.core.async channels.

Talking about clojure.core.async, my coworker mentioned that core.async really shines when you're waiting on more than one thing, otherwise core.async has no advantages over a linked blocking queue.

I think that is probably applicable to the Alda parser. We're using channels to make an asynchronous parsing pipeline. The results of each step in the pipeline feed into the next, but at no point is the receiving end waiting on multiple things.

It would be good to explore using LinkedBlockingQueues instead of core.async channels, to see if we can remove that dependency and make the Alda executable leaner.

[daveyarwood]

Another thing to try: transducers.

Should try both things and run the automated tests and see which approach is most performant.

[daveyarwood]

I started playing around with this and I eventually came to the realization that I was beginning to attempt to reimplement bits of core.async, like being able to close/terminate a channel, in the sense that the next step in the pipeline can read from it until it's closed (using <!!) and have a final value. I also started feeling weird about just throwing futures out there and hoping they won't leak too much memory. I suspect that core.async handles this in a sensible way... I know it has some sort of pool.

So, I think this idea may still have merit, but I don't really feel comfortable abandoning core.async (which I have come to trust) for a custom thing I build that will likely have a number of issues that have already been solved by core.async.