summaryrefslogtreecommitdiff
path: root/tools
diff options
context:
space:
mode:
authorRobin Gareus <robin@gareus.org>2016-12-13 23:46:55 +0100
committerRobin Gareus <robin@gareus.org>2016-12-13 23:47:07 +0100
commitfa07233a17036bc1cab69d5854b5c768ff762f5b (patch)
tree4048a4a6ca22845a9c80b0ecaf94a453b08b88da /tools
parent176625d9e0dbe53c9f5628d172ee6f5488be8202 (diff)
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.
Diffstat (limited to 'tools')
-rw-r--r--tools/luadevel/luasession.cc2
1 files changed, 2 insertions, 0 deletions
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;