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.
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.
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.
