As was noted in 88ee3af3ea it is unsafe/undefined behavior if two threads
sleep on the JACK request file descriptor, since there is no way to control
which one will wake and process the request. Since each thread may have
sent a different request, this can lead to a thread misinterpreting the
response because it is reading the wrong response.
This may (or may not) solve some subtle problems with JACK, but was
revealed by having a control surface (LaunchPad Pro) that registers
three ports from the butler thread at about the same as the GUI
thread is registering the auditioner. One thread read the wrong
response, and because of some slightly weird code/design, it attempts
to rename the port from within the response handler, which in JACK1
leads to deadlock (and later, zombification).
Because we use the non-callback API, we can call our thread init callback
ourselves from ::process_thread(). In addition, the init_callback in JACK is
used by every thread JACK creates, including the messagebuffer thread, and this
confuses things from an Ardour POV where the callback was intended just for
realtime threads.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
jack/systemdeps.h is jack2-only and contains many
windows-specific typedefs (native windows threads, ptw32 threads, MSVC
special cases etc etc.) which are not present in jack1/shared headers.
at the time the graph gets around to takes down
client threads, the jack-backend’s jack_client has been reset.
But never mind: libjack does not care about it, anyway.
