s6

Mirror/fork of https://skarnet.org/software/s6/
git clone https://ccx.te2000.cz/git/s6
Log | Files | Refs | README | LICENSE

commit 90acd08f35f9691753fdd523c6970365b6ea4b73
parent cb76026949fe9841b4f920a18bdb76827970c866
Author: Laurent Bercot <ska-skaware@skarnet.org>
Date:   Fri, 19 Dec 2014 01:24:53 +0000

 Doc fix

Diffstat:
Mdoc/libftrigr.html | 18+++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/doc/libftrigr.html b/doc/libftrigr.html @@ -76,7 +76,7 @@ for instance, illustrate how to use the ftrigr library. <ul> <li> Synchronous functions take a <tt>tain_t const *</tt> (<em>deadline</em>) parameter and a <tt>tain_t *</tt> (<em>stamp</em>) -parameter. Those are pointers to taia structures containing absolute times; +parameter. Those are pointers to tain_t structures containing absolute times; the former represents a deadline (in most cases, this time will be in the future) and the latter must be an accurate enough timestamp. These structures can be filled using the <tt>tain_</tt> primitives declared in @@ -85,13 +85,13 @@ structures can be filled using the <tt>tain_</tt> primitives declared in been made</strong> since the last time <em>stamp</em> was updated (by <tt>tain_now(&amp;stamp)</tt>). It's a good policy to always update <em>stamp</em> right after a (potentially) blocking system call like -<tt>select()</tt>returns. And unless the application is extremely CPU-intensive +<tt>select()</tt> returns. And unless the application is extremely CPU-intensive (think calculus for physicists or astronomers) updating <em>stamp</em> more frequently is unnecessary.) </li> <li> If such a synchronous function still hasn't returned when the deadline occurs, then it will immediately return a failure code and set errno to ETIMEDOUT. It is possible to pass null pointers to the function instead of pointers to -taia structures, in which case the function will never timeout. </li> +tain_t structures, in which case the function will never timeout. </li> <li> If a timeout occurs, the library does not guarantee proper interprocess communication later on; the application should either die, or at least close the communication channel and open a new one. </li> @@ -114,10 +114,10 @@ control on. </li> <pre> ftrigr_t a = FTRIGR_ZERO ; -struct taia deadline, stamp ; +tain_t deadline, stamp ; -taia_now(&amp;stamp) ; -taia_addsec(&amp;deadline, &amp;stamp, 2) +tain_now(&amp;stamp) ; +tain_addsec(&amp;deadline, &amp;stamp, 2) // char const *path = FTRIGR_IPCPATH ; // ftrigr_start(&amp;a, path, &amp;deadline, &amp;stamp) ; @@ -231,7 +231,7 @@ of usage examples.) </em> </p> <pre> -int ftrigr_fd (struct ftrigr const *a) +int ftrigr_fd (ftrigr_t const *a) </pre> <p> @@ -240,7 +240,7 @@ int ftrigr_fd (struct ftrigr const *a) </p> <pre> -int ftrigr_update (ftrigr_ref a) +int ftrigr_update (ftrigr_t *a) </pre> <p> @@ -260,7 +260,7 @@ integers. Those integers are ids waiting to be passed to </p> <pre> -int ftrigr_check (ftrigr_ref a, uint16 id, char *what) +int ftrigr_check (ftrigr_t *a, uint16 id, char *what) </pre> <p>