From feba8dd8df394119a041e40a5ac24b2fccb7507b Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sun, 29 Nov 2020 21:49:58 +0100 Subject: Save myself from trying to "properly" handle Jack shutdown again JACK is a wonderful idea. Shame about the software, though. --- src/JackLibDriver.cpp | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'src/JackLibDriver.cpp') diff --git a/src/JackLibDriver.cpp b/src/JackLibDriver.cpp index fd66e20..e5d3d23 100644 --- a/src/JackLibDriver.cpp +++ b/src/JackLibDriver.cpp @@ -255,7 +255,6 @@ JackLibDriver::refresh(const EventSink& sink) std::lock_guard lock{_shutdown_mutex}; if (!_client) { - _emit_event(DriverDetachmentEvent{ClientType::jack}); return; } @@ -473,6 +472,15 @@ JackLibDriver::on_shutdown(void* const driver) { auto* const me = static_cast(driver); + /* Note that the JACK documentation lies about this situation. It says the + client must not call jack_client_close() here... except that is exactly + what libjack does if a shutdown callback isn't registered. Despite + that, doing so here hangs forever. Handling it "properly" like a signal + handler and calling jack_client_close() in another thread also hangs. + + So, since JACK is a hot mess and it's impossible to gracefully handle + this situation, just leak the client. */ + std::lock_guard lock{me->_shutdown_mutex}; me->_client = nullptr; -- cgit v1.2.1