diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2020-12-08 16:04:48 +0100 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2020-12-08 20:42:39 +0100 |
commit | 69a9b48d50d98130a65aa6c823dc6cc464fefd71 (patch) | |
tree | defcf2cef8eb60721a4bf389ca051bff4e163a12 /vcl/README.scheduler | |
parent | ce8a8e809dedc61d8355560914f78987ee11f1e2 (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.scheduler | 14 |
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"... |