- Parallel build fix v2.0.1.0

 - Complete readiness notification via supervise/ready
 - Version updated to 2.0.1.0, release candidate

5 files changed, 39 insertions, 26 deletions

diff --git a/doc/index.html b/doc/index.html
index bf8d0ae..1507705 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -52,9 +52,9 @@ supervision that might help you understand the basics.
  <li> A POSIX-compliant system with a standard C development environment </li>
  <li> GNU make, version 4.0 or later </li>
  <li> <a href="http://skarnet.org/software/skalibs/">skalibs</a> version
-2.1.0.0 or later </li>
+2.2.0.0 or later </li>
  <li> <a href="http://skarnet.org/software/execline/">execline</a> version
-2.0.0.0 or later </li>
+2.0.1.1 or later </li>
 </ul>
 
 <h3> Licensing </h3>
@@ -67,7 +67,7 @@ supervision that might help you understand the basics.
 <h3> Download </h3>
 
 <ul>
- <li> The current released version of s6 is <a href="s6-2.0.0.1.tar.gz">2.0.0.1</a>. </li>
+ <li> The current released version of s6 is <a href="s6-2.0.1.0.tar.gz">2.0.1.0</a>. </li>
  <li> Alternatively, you can checkout a copy of the s6 git repository:
 <pre> git clone git://git.skarnet.org/s6 </pre> </li>
 </ul>
diff --git a/doc/notifywhenup.html b/doc/notifywhenup.html
index f73e2aa..6847cb2 100644
--- a/doc/notifywhenup.html
+++ b/doc/notifywhenup.html
@@ -42,25 +42,28 @@ daemon may not be ready yet.
 
 <p>
  Reliable startup notifications need support from the daemons themselves.
-Daemons should notify the outside world when the service they are providing
-is reliably up - because only they know when it is the case.
-</p>
-
-<p>
- s6 provides two ways for daemons to perform startup notification.
+Daemons should do two things to signal the outside world that they are
+ready:
 </p>
 
 <ol>
- <li> Daemons can use the <tt>ftrigw_notify()</tt> function, provided in
-<a href="libftrigw.html">the ftrigw library</a>. This is extremely
-simple and efficient, but requires specific s6 support in the daemon. </li>
- <li> Daemons can write a line to a file descriptor of their choice,
+ <li> Update a state file, so other processes can get a snapshot
+of the daemon's state </li>
+ <li> Send an event to processes waiting for a state change. </li>
+</ol>
+
+<p>
+ This is complex to implement in every single daemon, so s6 provides
+tools to make it easier for daemon authors, without any need to link
+against the s6 library or use any s6-specific construct:
+ daemons can simply write a line to a file descriptor of their choice,
 then close that file descriptor, when they're ready to serve. This is
-a generic mechanism that some daemons already implement, and does not
-require anything specific in the daemon's code. The administrator can
+a generic mechanism that some daemons already implement.
+The administrator can
 then run the daemon under <a href="s6-notifywhenup.html">s6-notifywhenup</a>,
-which will properly catch the daemon's message and notify all the subscribers
-with a 'U' event, meaning that the service is now up. <br /> <br />
+which will properly catch the daemon's message and update a state file
+itself, then notify all the subscribers
+with a 'U' event, meaning that the service is now up. <br />
  Note that there is <em>still</em> a small race condition remaining:
 if the daemon writes a line then instantly dies, and the supervisor
 picks up the death before the <a href="s6-notifywhenup.html">s6-notifywhenup</a>
@@ -69,11 +72,10 @@ to the fifodir to be wrong - 'd' before 'U'. This should be extremely
 rare, but unfortunately the race condition is unavoidable. The only
 way to be absolutely race-free is to have the daemon perform its
 readiness notification itself, which requires specific support.
- </li>
-</ol>
+</p>
 
 <p>
- The second method should really be implemented in every long-running
+ This method should really be implemented in every long-running
 program providing a service. When it is not the case, it's impossible
 to provide reliable startup notifications, and subscribers should then
 be content with the unreliable 'u' events provided by s6-supervise.
diff --git a/doc/s6-notifywhenup.html b/doc/s6-notifywhenup.html
index f192ca4..b772925 100644
--- a/doc/s6-notifywhenup.html
+++ b/doc/s6-notifywhenup.html
@@ -38,7 +38,8 @@ needed.
  <li> s6-notifywhenup forks and executes <em>prog...</em> as the
 parent, with a pipe from <em>prog...</em>'s stdout to the child. </li>
  <li> The child waits for a newline (<tt>\n</tt>) to be written
-on the pipe. When it gets it, it sends a 'U' event to the
+on the pipe. When it gets it, it creates an empty
+<tt>./supervise/ready</tt> file then sends a 'U' event to the
 <tt>./event</tt> fifodir. </li>
  <li> The child exits 0. </li>
 </ul>
diff --git a/doc/s6-svwait.html b/doc/s6-svwait.html
index 6e15704..5f3cb08 100644
--- a/doc/s6-svwait.html
+++ b/doc/s6-svwait.html
@@ -33,7 +33,7 @@ s6-svwait only waits for notifications; it never polls.
 
 <p>
 s6-svwait monitors one or more <a href="servicedir.html">service
-directories</a> given as its arguments, waiting for a state (up or down) to
+directories</a> given as its arguments, waiting for a state (ready, up or down) to
 happen. It exits 0 when the wanted condition becomes true.
 </p>
 
@@ -46,8 +46,10 @@ This is the default; it is not reliable, but it does not depend on specific
 support in the service programs. See <a href="notifywhenup.html">this page</a>
 for details. </li>
  <li> <tt>-U</tt>&nbsp;: really up. s6-svwait will wait until the services are
-up, as reported by the services themselves. This requires specific support in the
-service programs: see the explanation on <a href="notifywhenup.html">this page</a>. </li>
+up <em>and</em> ready as reported by the services themselves. This requires
+specific support in the service programs, and the use of
+<a href="s6-notifywhenup.html">s6-notifywhenup</a> in the service's run script.
+See the explanation on <a href="notifywhenup.html">this page</a>. </li>
  <li> <tt>-d</tt>&nbsp;: down. s6-svwait will wait until the services are down. </li>
  <li> <tt>-o</tt>&nbsp;: or. s6-svwait will wait until <em>one</em> of the
 given services comes up or down. </li>
@@ -59,13 +61,13 @@ to stderr and exit 1. By default, <em>timeout</em> is 0, which means no time
 limit. </li>
 </ul>
 
-
 <h2> Internals </h2>
 
 <p>
 s6-svwait spawns a <a href="s6-ftrigrd.html">s6-ftrigrd</a> child to
 listen to notifications sent by <a href="s6-supervise.html">s6-supervise</a>.
-It also checks <tt>supervise/status</tt> files to get the current service
+It also checks <tt>supervise/status</tt> files, as well as the
+<tt>supervise/ready</tt> files if necessary, to get the current service
 states, so it is immune to race conditions.
 </p>
 
diff --git a/doc/upgrade.html b/doc/upgrade.html
index 789d425..0851534 100644
--- a/doc/upgrade.html
+++ b/doc/upgrade.html
@@ -17,6 +17,14 @@
 
 <h1> What has changed in s6 </h1>
 
+<h2> in 2.0.1.0 </h2>
+
+<ul>
+ <li> skalibs dependency bumped to 2.2.0.0. </li>
+ <li> execline dependency bumped to 2.0.1.1. </li>
+ <li> Better readiness notification management via s6-svwait -U. </li>
+</ul>
+
 <h2> in 2.0.0.1 </h2>
 
 <ul>