From 0eaed088d2837d8c2c1f7c815b0e365824087d58 Mon Sep 17 00:00:00 2001 From: root Date: Wed, 3 Nov 2010 20:03:21 +0000 Subject: *** empty log message *** --- ev.pod | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'ev.pod') diff --git a/ev.pod b/ev.pod index 7e2f9ef..a9009ee 100644 --- a/ev.pod +++ b/ev.pod @@ -404,14 +404,14 @@ environment variable. =item C When this flag is specified, then libev will not attempt to use the -I API for it's C watchers. Apart from debugging and +I API for its C watchers. Apart from debugging and testing, this flag can be useful to conserve inotify file descriptors, as otherwise each loop using C watchers consumes one inotify handle. =item C When this flag is specified, then libev will attempt to use the -I API for it's C (and C) watchers. This API +I API for its C (and C) watchers. This API delivers signals synchronously, which makes it both faster and might make it possible to get the queued signal data. It can also simplify signal handling with threads, as long as you properly block signals in your @@ -621,7 +621,7 @@ C, but it can also be used on the default loop returned by C, in which case it is not thread-safe. Note that it is not advisable to call this function on the default loop -except in the rare occasion where you really need to free it's resources. +except in the rare occasion where you really need to free its resources. If you need dynamically allocated loops it is better to use C and C. @@ -2262,7 +2262,7 @@ Example: Call a callback every hour, starting now: Signal watchers will trigger an event when the process receives a specific signal one or more times. Even though signals are very asynchronous, libev -will try it's best to deliver signals synchronously, i.e. as part of the +will try its best to deliver signals synchronously, i.e. as part of the normal event processing, like any other event. If you want signals to be delivered truly asynchronously, just use -- cgit v1.2.3