From b0fe68c13b04af8c098d53ea999bba6b7395163d Mon Sep 17 00:00:00 2001
From: Laurent Bercot <ska-skaware@skarnet.org>
Date: Wed, 16 Sep 2020 12:04:55 +0000
Subject:  Documentation fixes, by flexibeast

---
 doc/ftrig.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

(limited to 'doc/ftrig.html')

diff --git a/doc/ftrig.html b/doc/ftrig.html
index 6d26eeb..c8f168d 100644
--- a/doc/ftrig.html
+++ b/doc/ftrig.html
@@ -73,7 +73,7 @@ it's not handling an event, and only wake up when needed.
  Of course, the problem of notification is that it's often more difficult
 to implement. Notification frameworks are generally more complex, involving
 lots of asynchronism; polling is widely used
-<a href="http://lib.store.yahoo.net/lib/demotivators/mediocritydemotivationalposter.jpg">because
+<a href="https://lib.store.yahoo.net/lib/demotivators/mediocritydemotivationalposter.jpg">because
 it's easy.</a>
 </p>
 
@@ -86,11 +86,11 @@ notify process A.
 
 <ul>
  <li> Signals. The simplest Unix notification mechanism. Sending events amounts
-to a <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html">kill()</a>
-call, and receiving events amounts to installing a signal handler (preferrably
+to a <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html">kill()</a>
+call, and receiving events amounts to installing a signal handler (preferably
 using a <a href="//skarnet.org/software/skalibs/libstddjb/selfpipe.html">self-pipe</a>
 if mixing signals with an event loop). Unfortunately, Unix signals, even the more
-recent and powerful real-time Posix signals, have important limitations when it's
+recent and powerful real-time POSIX signals, have important limitations when it's
 about generic notification:
  <ul>
   <li> non-root processes can only send signals to a very restricted and
-- 
cgit 1.4.1