Oliver Jowett

.. though I guess that wouldn't happen with a zero exit code either, since the service is set up with `Restart=on-failure`

I'm fine with changing it to 0, I think that still works with the way the service is set up

Test case showing the problem: ``` #include #include #include #include #include static LatLng goodVerts[] = { {-74, -120}, {-74, 0}, {-74, 120}, {-82, 120}, {-82, 0}, {-82, -120} }; static...

On restart of the process, to reduce the recovery time? Loading from the cache seems to be substantially faster than loading by running the query.

Packages that want to use stapi that are not aware of each other.

For schemas with no change-timestamp and where rows are never deleted, the current situation works. For schemas with no change-timestamp and where rows are deleted, the current situation does not...

Note that most of fa_sudo only exists because currently, tcl's tendency to eat exit status means that if you care about asynchronous exit status, you have to reimplement it all...

Can you use the advanced monitoring stuff on a non-blocking, _non-closed_ pipeline? EOF of a pipeline and process exit are distinct events so when working with a pipeline in nonblocking...

Also, when you say it only worked on DETACHED processes: how do other child PIDs behave, do they show up with no data or not appear at all or what?

A couple of comments: 1. blocking _all_ signals in the signal handling thread is probably not right. It means that all signals delivered directly to that thread will be treated...