mirror of
https://github.com/Ardour/ardour.git
synced 2025-12-06 06:44:57 +01:00
libpbd: fix an important thinko for cross-thread signal architecture
The old code assumed that the thread that created a request buffer for a given signal-emitting thread would be the latter thread, and thus a thread-local pointer to the request buffer could be used. This turns out not to be true: the GUI thread tends to be responsible for constructing the request buffers for pre-registered threads. That mechanism has been replaced by using a RWLock protected map using pthread_t as the key and the request buffer as the value. This allows any thread to create and register the request buffers used between any other pair of threads (because the lookup always uses a pthread_t). The symptoms of this problem were a signal emitted in an audioengine thread that was propagated to the target thread, but when the target thread scans its request buffers for requests, it finds nothing (because it didn't know about the request buffer). In a sense, the signal was successfully delivered to the target thread, but no meaningful work (i.e the signal handler) is performed.
This commit is contained in:
parent
6eec11e50e
commit
5d023b4c60
7 changed files with 52 additions and 45 deletions
|
|
@ -103,11 +103,11 @@ class MyEventLoop : public sigc::trackable, public EventLoop
|
|||
return true;
|
||||
}
|
||||
|
||||
Glib::Threads::Mutex& slot_invalidation_mutex() { return request_buffer_map_lock; }
|
||||
Glib::Threads::RWLock& slot_invalidation_rwlock() { return request_buffer_map_lock; }
|
||||
|
||||
private:
|
||||
Glib::Threads::Thread* run_loop_thread;
|
||||
Glib::Threads::Mutex request_buffer_map_lock;
|
||||
Glib::Threads::RWLock request_buffer_map_lock;
|
||||
};
|
||||
|
||||
static MyEventLoop *event_loop;
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue