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

[Andrea Gelmini]

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

New commits:
commit ddcdd4a59543fb8e4b6daefe12f3c7e9a8ca0765
Author: Andrea Gelmini <andrea.gelmini at gelma.net>
Date:   Fri Sep 22 11:23:45 2017 +0200

    Fix typos
    
    Change-Id: I51700733fda3a08570085ed6745961cd1680eabd
    Reviewed-on: https://gerrit.libreoffice.org/42588
    Reviewed-by: Tamás Zolnai <tamas.zolnai at collabora.com>
    Tested-by: Tamás Zolnai <tamas.zolnai at collabora.com>

diff --git a/vcl/README.scheduler b/vcl/README.scheduler
index 7e80c1f04eb8..deca0d296201 100644
--- a/vcl/README.scheduler
+++ b/vcl/README.scheduler
@@ -105,7 +105,7 @@ SolarMutex acquire and release calls, so the calling and the main thread
 don't deadlock. Those wakeup events must be ignored to prevent busy-locks.
 
 We can neither rely on MacOS dispatch_sync code block execution nor the
-message handling, as both can't be priorized or filtered and the first
+message handling, as both can't be prioritized or filtered and the first
 does also not allow nested execution and is just processed in sequence.
 
 There is also a workaround for a problem for pushing tasks to an empty queue,
@@ -188,5 +188,5 @@ Instead of LO running in the main process / thread, we run it in a 2nd thread
 and defer al GUI calls to the main thread. This way it'll hopefully not block
 and can process system events.
 
-That's just a theory - it definitly needs more analysis before even attemding
+That's just a theory - it definitely needs more analysis before even attending
 an implementation.