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).
Without this, two threads can both sleep on the same communication channel, and the wake order
is non-determinate, so the wrong thread may process the response to the other thread's request.
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.
jack1 (which is Linux only) does not have a jack_client_stop_thread
API, and expects the application to call pthread_join().
This fixes an issue when the application is compiled using jack2 headers
but the application later runs using jack1's library.
If connecting ports using the port-engine fails,
ardour forgets the connection.
Internal backends only produced an error if a port was already
connected, when using ::connect (handle, other), but
ignore already existing connection when using port-names.
Various ports are connected twice when the engine connects
at session load. This worked fine for as long as the engine
was never stopped (saving the session asks the port-engine),
but failed when the engine went away and internal representation
is used.
