summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrea Gelmini <andrea.gelmini@gelma.net>2019-08-13 17:05:37 +0200
committerAndrea Gelmini <andrea.gelmini@gelma.net>2019-08-13 18:57:27 +0200
commit08097a2eef5e827735af3e5e69b30d23ee213970 (patch)
treef372ddc21cd3820c65ff99309714c0999dbeb322
parent36432802bc955bed05fb87bef8053bd3b06411f0 (diff)
Fix typos
Change-Id: I5c3d7a041f0d654d04d8cbe71393921ed46c1220 Reviewed-on: https://gerrit.libreoffice.org/77426 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
-rw-r--r--include/vcl/TaskStopwatch.hxx8
-rw-r--r--vcl/README.scheduler6
2 files changed, 7 insertions, 7 deletions
diff --git a/include/vcl/TaskStopwatch.hxx b/include/vcl/TaskStopwatch.hxx
index c98dcc6f5527..fdcc6bdf2ed4 100644
--- a/include/vcl/TaskStopwatch.hxx
+++ b/include/vcl/TaskStopwatch.hxx
@@ -18,7 +18,7 @@
/**
* Helper class primary used to track time of long running iterating tasks.
*
- * Normally it should be sufficiant to instanciate the watch object before
+ * Normally it should be sufficient to instantiate the watch object before
* starting the iteration and query continueIter() at the end of each.
*
* Called Stopwatch, because there is already a Timer class in the Scheduler.
@@ -65,13 +65,13 @@ class VCL_DLLPUBLIC TaskStopwatch
public:
/**
- * Per default the watch consideres the last iter time when asking for an
+ * Per default the watch considers the last iter time when asking for an
* other iteration, so considers Scheduler::acceptableTaskTime as a
* maximum value.
*
* If you already know your iter time vary in a large range, consider
* setting bConciderLastIterTime to false, so Scheduler::acceptableTaskTime
- * will be used as a mimimum time slot.
+ * will be used as a minimum time slot.
**/
TaskStopwatch(bool bConciderLastIterTime = true)
: m_nStartTicks(tools::Time::GetSystemTicks())
@@ -87,7 +87,7 @@ public:
bool exceededRuntime() { return !nextIter(true); }
/**
- * Returns true, if an other iteration will probably pass in the time slot
+ * Returns true, if another iteration will probably pass in the time slot
**/
bool continueIter() { return nextIter(false); }
diff --git a/vcl/README.scheduler b/vcl/README.scheduler
index a05a291bc1c3..52c76dac5b85 100644
--- a/vcl/README.scheduler
+++ b/vcl/README.scheduler
@@ -176,7 +176,7 @@ versions are processed but simply don't run the scheduler.
== General: track time of long running tasks ==
-There is TaskStopwatch class. It'll track the time and report a timout either
+There is TaskStopwatch class. It'll track the time and report a timeout either
when the tasks time slice is finished or some system event did occur.
Eventually it will be merged into the main scheduler, so each invoked task can
@@ -189,7 +189,7 @@ There were some questions coming up when implementing it:
and skip the instant timeout? ===
You never know how long a task will run. Currently the scheduler simply asks
-each task when it'll be ready to run, until two runable tasks are found.
+each task when it'll be ready to run, until two runnable tasks are found.
Normally this is very quick, as LO has a lot of one-shot instant tasks / Idles
and just a very few long term pending Timers.
@@ -207,7 +207,7 @@ term timer list increases AKA for highly loaded LOOL instances.
But the Linux timer wheel mainly relies on the facts that the OS timers are
expected to not expire, as they are use to catch "error" timeouts, which rarely
-happen, so this definitly not matches LO's usage.
+happen, so this definitely not matches LO's usage.
=== Not really usable to find misbehaving tasks ===