From fa07233a17036bc1cab69d5854b5c768ff762f5b Mon Sep 17 00:00:00 2001 From: Robin Gareus Date: Tue, 13 Dec 2016 23:46:55 +0100 Subject: mutex 'er up Some overzealous locking to track down RequestObject related crashes. bc0fa4d689a4 wrongly locked the current event loop's request_invalidation_lock instead of the invalidation's list lock. Also Abstract UI is able to delete requests concurrently with with EventLoop invalidation. e.g. PortManager::PortRegisteredOrUnregistered and GlobalPortMatrixWindow so the lock needs to be exposed. If this solves various issues, mutexes should to be consolidated (request_buffer_map_lock + request_invalidation_lock) and be chosen such that there is as little contention as possible. --- tools/luadevel/luasession.cc | 2 ++ 1 file changed, 2 insertions(+) (limited to 'tools/luadevel/luasession.cc') diff --git a/tools/luadevel/luasession.cc b/tools/luadevel/luasession.cc index a131bb443f..649346b3f7 100644 --- a/tools/luadevel/luasession.cc +++ b/tools/luadevel/luasession.cc @@ -109,10 +109,12 @@ class MyEventLoop : public sigc::trackable, public EventLoop } Glib::Threads::Mutex& slot_invalidation_mutex () { return request_buffer_map_lock; } + Glib::Threads::Mutex& request_invalidation_mutex() { return request_invalidation_lock; } private: Glib::Threads::Thread* run_loop_thread; Glib::Threads::Mutex request_buffer_map_lock; + Glib::Threads::Mutex request_invalidation_lock; }; static MyEventLoop *event_loop = NULL; -- cgit v1.2.3