[Libreoffice-commits] core.git: vcl/README.scheduler

[Andrea Gelmini (via logerrit)]

 vcl/README.scheduler |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 1d3421ce32025902a6c5091f396507ddd4674b8e
Author:     Andrea Gelmini <andrea.gelmini at gelma.net>
AuthorDate: Mon Dec 7 22:42:13 2020 +0100
Commit:     Julien Nabet <serval2412 at yahoo.fr>
CommitDate: Wed Dec 9 18:33:01 2020 +0100

    Fix typos
    
    Change-Id: I78ce1be18e80886ae7c7079113d47420a3c864c4
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107367
    Tested-by: Jenkins
    Reviewed-by: Julien Nabet <serval2412 at yahoo.fr>

diff --git a/vcl/README.scheduler b/vcl/README.scheduler
index e08f59e37cdf..263fe329bc3d 100644
--- a/vcl/README.scheduler
+++ b/vcl/README.scheduler
@@ -58,12 +58,12 @@ Task::mpSchedulerData, which is actually a part of the scheduler.
 Before invoking the task, we have to release the lock, so others can
 Start new Tasks.
 
-The Scheduler just processes it's own Tasks in the main thread and needs
+The Scheduler just processes its 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 scheduler mutex or don't need locking
 at all.
 
-There is a "workaround" for static Task objecs, which would crash LO on
+There is a "workaround" for static Task objects, which would crash LO on
 destruction, because Task::~Task would try to de-register itself in the
 Scheduler, while the SchedulerLock would be long gone. OTOH this makes
 Task handling less error-prone, than doing "special" manual cleanup.