January

Monday January 20th

I have an ongoing problem: features I develop in C which run cleanly often seem to break in strange ways when wrapped for python instruments.

Strange, inscrutible ways usually with messages just never arriving, or threads seeming going totally silent. When I manage to catch it in the act somewhat, it seems caught somewhere in the plumbing of the multiprocessing module.

I wonder if I can eliminate python concurrency entirely. I’ve moved as much of it as possible to C, which is a delight to debug compared to python, frankly. There is way way too much magic in the multiprocessing library, even when restricting myself to just the SimpleQueue (the standard Queue has so much magic SimpleQueue needed to be created – switching to it solved a whole class of issues with messages arrriving in totally incoherent ways) I regularly run into pathological behavior with message passing.

A few days before a show isn’t the right time, probably, but I need to simplify the python render pool again. Maybe something really ridiclous like a standalone C renderer with an embdedded interpter per comrade (I like to call thread workers comrades because we all need some way to feel sane in a world of capitalist asshats) managed via POSIX message queues? Incredibly I wouldn’t be surprised if that was a lot more stable. It complicates loading the python environment though – at least with the old CPython API it did. I had some success with the new API, which at this point I think has already been in cpython for a couple versions?

Meanwhile I’m just writing C instruments for now, and not really missing live coding too much. I do miss it the most at this stage in developing an instrument though. Trying new ideas out is much slower, but also much more stable.

(oops I missed September!)