summaryrefslogtreecommitdiff
path: root/vcl/README.scheduler
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2020-12-08 16:04:48 +0100
committerStephan Bergmann <sbergman@redhat.com>2020-12-08 20:42:39 +0100
commit69a9b48d50d98130a65aa6c823dc6cc464fefd71 (patch)
treedefcf2cef8eb60721a4bf389ca051bff4e163a12 /vcl/README.scheduler
parentce8a8e809dedc61d8355560914f78987ee11f1e2 (diff)
Replace SchedulerMutex with (non-recursive) std::mutex
...following up on the TODO from 84af20ef3ea72190784e9e7be820684c2558ba8c "Make SchedulerMutex non-recursive" Change-Id: I3be98f2dba7c7486b79ec1f166431333cc69451a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107423 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'vcl/README.scheduler')
-rw-r--r--vcl/README.scheduler14
1 files changed, 4 insertions, 10 deletions
diff --git a/vcl/README.scheduler b/vcl/README.scheduler
index 466485f16645..e08f59e37cdf 100644
--- a/vcl/README.scheduler
+++ b/vcl/README.scheduler
@@ -60,7 +60,7 @@ Start new Tasks.
The Scheduler just processes it's own Tasks in the main thread and needs
the SolarMutex for it and for DeInit (tested by DBG_TESTSOLARMUTEX). All
-the other interaction just take the SchedulerMutex or don't need locking
+the other interaction just take the scheduler mutex or don't need locking
at all.
There is a "workaround" for static Task objecs, which would crash LO on
@@ -69,9 +69,9 @@ Scheduler, while the SchedulerLock would be long gone. OTOH this makes
Task handling less error-prone, than doing "special" manual cleanup.
There is also a "= TODOs and ideas =" to get rid if static Tasks.
-Actually the SchedulerMutex should never be locked when calling into
-non-scheduler code, so it was converted to simulate a non-recursive
-mutex later. As an alternative it could use a std::mutex.
+Actually the scheduler mutex should never be locked when calling into
+non-scheduler code, so it was converted to a non-recursive
+std::mutex.
= Lifecycle / thread-safety of Scheduler-based objects =
@@ -407,9 +407,3 @@ will also affect the Gtk+ and KDE backend for the user event handling.
This way it can be easier used to profile Tasks, eventually to improve LO's
interactivity.
-
-== Convert SchedulerMutex to std::mutex ==
-
-Since the SchedulerMutex is non-recursive, it could use a std::mutex instead
-of simulating one still using the osl::Mutex. Not sure, if a deadlock instead
-of a crash, when called recursively, is the better "user experience"...