From cb1dd13235be8954b5881bc390d4813177ce4137 Mon Sep 17 00:00:00 2001 From: Ruslan Osmanov Date: Thu, 27 Dec 2012 16:33:36 +0000 Subject: [PATCH] Del: 'you' word git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@328909 c90b9560-bf6c-de11-be94-00142212c4b1 --- reference/ev/book.xml | 19 ++++++++---- reference/ev/ev.xml | 40 ++++++++++++------------- reference/ev/ev/feedsignal.xml | 2 +- reference/ev/ev/feedsignalevent.xml | 2 +- reference/ev/ev/recommendedbackends.xml | 6 ++-- reference/ev/ev/resume.xml | 9 +++--- reference/ev/ev/suspend.xml | 9 +++--- reference/ev/evcheck.xml | 19 ++++++------ reference/ev/evchild.xml | 4 +-- reference/ev/evchild/construct.xml | 18 +++++------ reference/ev/evembed/construct.xml | 2 +- reference/ev/evidle.xml | 8 ++--- reference/ev/evio.xml | 32 ++++++++++---------- reference/ev/evloop.xml | 26 ++++++++-------- reference/ev/evperiodic.xml | 18 +++++------ reference/ev/evperiodic/again.xml | 2 +- reference/ev/evperiodic/construct.xml | 6 ++-- reference/ev/evsignal.xml | 23 +++++++------- reference/ev/evsignal/construct.xml | 7 +++-- reference/ev/evsignal/createstopped.xml | 2 +- reference/ev/evstat.xml | 8 ++--- reference/ev/evtimer.xml | 12 ++++---- reference/ev/evwatcher.xml | 14 +++++---- reference/ev/evwatcher/keepalive.xml | 25 ++++++++-------- reference/ev/periodic-modes.xml | 12 ++++---- reference/ev/watcher-callbacks.xml | 2 +- reference/ev/watchers.xml | 17 +++++------ 27 files changed, 176 insertions(+), 168 deletions(-) diff --git a/reference/ev/book.xml b/reference/ev/book.xml index 96c7219b3f..f59f266294 100644 --- a/reference/ev/book.xml +++ b/reference/ev/book.xml @@ -16,17 +16,24 @@ ¬e.no-windows.extension; - Libev is an event loop: you register interest in certain - events (such as a file descriptor being readable or a timeout occurring), and - it will manage these event sources and provide your program with events. - - To do this, it must take more or less complete control over your process (or - thread) by executing the event loop handler, and will then communicate events + Libev is an event loop: one registers interest in + certain events (such as a file descriptor being readable or a timeout + occurring), and it will manage these event sources and provide the program + with events. + + + + To do this, it must take more or less complete control over the process (or + thread) by executing the event loop handler, and will then communicate events via a callback mechanism. + + You register interest in certain events by registering so-called event watchers, and then hand it over to libev by starting the watcher. + + For details refer to the documentation of libev diff --git a/reference/ev/ev.xml b/reference/ev/ev.xml index 370cfdf3df..d8ea3408bd 100644 --- a/reference/ev/ev.xml +++ b/reference/ev/ev.xml @@ -282,7 +282,7 @@ EvLoop::fork manually. This works by calling getpid() on every iteration of - the loop, and thus this might slow down your event loop if you do a lot of + the loop, and thus this might slow down the event loop with lots of loop iterations, but usually is not noticeable. This flag setting cannot be overridden or specified in the @@ -317,9 +317,8 @@ xlink:href="http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#code_ev_child_code_watch_out_for_pro">ev_child) 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 threads that are not interested in handling them. - + also simplify signal handling with threads, as long as signals are + properly blocked in threads. Signalfd will not be used by default. @@ -330,12 +329,12 @@ When this flag is specified, libev will avoid to - modify the signal mask. Specifically, this means you have to make sure - signals are unblocked when you want to receive them. - - This behaviour is useful when you want to do your own signal handling, or - want to handle signals only in specific threads and want to avoid - libev unblocking the signals. + modify the signal mask. Specifically, this means having to make sure + signals are unblocked before receiving them. + + + This behaviour is useful for custom signal handling, or handling signals + only in specific threads. @@ -351,7 +350,7 @@ Means that event loop will look for new events, will handle those events - and any already outstanding ones, but will not wait and block your + and any already outstanding ones, but will not wait and block the process in case there are no events and will return after one iteration of the loop. This is sometimes useful to poll and handle new events while doing lengthy calculations, to keep the program responsive. @@ -365,7 +364,7 @@ Means that even loop will look for new events(waiting if necessary) and will handle those and any already outstanding ones. It - will block your process until at least one new event arrives (which could + will block the process until at least one new event arrives (which could be an event internal to libev itself, so there is no guarantee that a user-registered callback will be called), and will return after one iteration of the loop. @@ -618,7 +617,7 @@ kqueue backend used on most BSD systems. EvEmbed watcher could be used to embed one - loop(with kqueue backend) into another. For instance, you can try to + loop(with kqueue backend) into another. For instance, one can try to create an event loop with kqueue backend and use it for sockets only. @@ -648,7 +647,7 @@ Try all backends(even currupted ones). It's not recommended to use it - explicitly. You should apply bitwise operators(e.g. + explicitly. Bitwise operators should be applied here(e.g. Ev::BACKEND_ALL & ~Ev::BACKEND_KQUEUE) Use Ev::recommendedBackends, or don't specify any @@ -661,10 +660,9 @@ Ev::BACKEND_MASK - Not a backend, but a mask to select all backend bits from a - flags value, in case you want to mask out any - backends from a flags value (e.g. when modifying the - LIBEV_FLAGS environment variable). + Not a backend, but a mask to select all backend bits from + flags value to mask out any backends(e.g. when + modifying the LIBEV_FLAGS environment variable). @@ -687,9 +685,9 @@ loop in Ev class(e.g. Ev::iteration, Ev::depth etc.) For custom loops(created with - EvLoop::__construct) you can access these values - via corresponding properties and methods of the EvLoop - class. + EvLoop::__construct) these values may be accessed + via corresponding properties and methods of the + EvLoop class. diff --git a/reference/ev/ev/feedsignal.xml b/reference/ev/ev/feedsignal.xml index 228d01ba52..0d45b8d83b 100644 --- a/reference/ev/ev/feedsignal.xml +++ b/reference/ev/ev/feedsignal.xml @@ -16,7 +16,7 @@ Simulates a signal receive. It is safe to call this function at any time, from any context, including signal handlers or random threads. - Its main use is to customise signal handling in your process. + Its main use is to customise signal handling in the process. Unlike Ev::feedSignalEvent, this works regardless diff --git a/reference/ev/ev/feedsignalevent.xml b/reference/ev/ev/feedsignalevent.xml index 126d9e2a42..dbc52180fb 100644 --- a/reference/ev/ev/feedsignalevent.xml +++ b/reference/ev/ev/feedsignalevent.xml @@ -29,7 +29,7 @@ Signal number. See signal(7) man page for detals. - You can use constants exported by pcntl extension. + See also constants exported by pcntl extension. diff --git a/reference/ev/ev/recommendedbackends.xml b/reference/ev/ev/recommendedbackends.xml index 65818b3f0e..c85f3a813e 100644 --- a/reference/ev/ev/recommendedbackends.xml +++ b/reference/ev/ev/recommendedbackends.xml @@ -20,9 +20,9 @@ will work for most file descriptor types. This set is often smaller than the one returned by ev_supported_backends, as for example kqueue is broken on most BSD systems - and will not be auto-detected unless you explicitly request it. This is the - set of backends that libev will probe for you if you - specify no backends explicitly. + and will not be auto-detected unless it is requested explicitly. This is the + set of backends that libev will probe no backends + specified explicitly. diff --git a/reference/ev/ev/resume.xml b/reference/ev/ev/resume.xml index 00d2ecaf4f..9aa8dfa0e8 100644 --- a/reference/ev/ev/resume.xml +++ b/reference/ev/ev/resume.xml @@ -27,10 +27,11 @@ - After calling Ev::suspend you must not call any - function on the given loop other than Ev::resume, - and you must not call Ev::resume - without a previous call to Ev::suspend. + After calling Ev::suspend it is not allowed to call + any function on the given loop other than + Ev::resume. Also it is not allowed to call + Ev::resume without a previous call to + Ev::suspend. diff --git a/reference/ev/ev/suspend.xml b/reference/ev/ev/suspend.xml index e85f92eb78..093902c000 100644 --- a/reference/ev/ev/suspend.xml +++ b/reference/ev/ev/suspend.xml @@ -28,10 +28,11 @@ - After calling Ev::suspend you must not call any - function on the given loop other than Ev::resume, - and you must not call Ev::resume - without a previous call to Ev::suspend. + After calling Ev::suspend it is not allowed to call + any function on the given loop other than + Ev::resume. Also it is not allowed to call + Ev::resume without a previous call to + Ev::suspend. diff --git a/reference/ev/evcheck.xml b/reference/ev/evcheck.xml index 364394073f..cb53bc1964 100644 --- a/reference/ev/evcheck.xml +++ b/reference/ev/evcheck.xml @@ -18,23 +18,22 @@ EvCheck afterwards. - You must not call EvLoop::run or similar methods + It is not allowed to call EvLoop::run or similar methods or functions that enter the current event loop from either - EvPrepare or - EvCheck watchers. Other loops than the current one are fine, however. The - rationale behind this is that you do not need to check for recursion in - those watchers, i.e. the sequence will always be: + EvPrepare or EvCheck + watchers. Other loops than the current one are fine, however. The + rationale behind this is that one don't need to check for recursion + in those watchers, i.e. the sequence will always be: EvPrepare -> blocking -> - EvCheck, so if you have one watcher of each kind they will always be called - in pairs bracketing the blocking - call. + EvCheck, so having a watcher of each kind they will + always be called in pairs bracketing the blocking call. The main purpose is to integrate other event mechanisms into libev and their use is somewhat advanced. They could - be used, for example, to track variable changes, implement your own + be used, for example, to track variable changes, implement custom watchers, integrate net-snmp or a coroutine library and lots more. They are - also occasionally useful if you cache some data and want to flush it before + also occasionally useful to cache some data and want to flush it before blocking. diff --git a/reference/ev/evchild.xml b/reference/ev/evchild.xml index 80ac05dfdb..35b7453243 100644 --- a/reference/ev/evchild.xml +++ b/reference/ev/evchild.xml @@ -12,9 +12,9 @@
&reftitle.intro; - EvChild watchers trigger when your process receives + EvChild watchers trigger when the process receives a SIGCHLD in response to some child status changes - (most typically when a child of yours dies or exits). It is permissible to + (most typically when a child dies or exits). It is permissible to install an EvChild watcher after the child has been forked(which implies it might have already exited), as long as the event loop isn't entered(or is continued from a watcher), i.e. forking and then diff --git a/reference/ev/evchild/construct.xml b/reference/ev/evchild/construct.xml index 40c70a36e7..cffaed7555 100644 --- a/reference/ev/evchild/construct.xml +++ b/reference/ev/evchild/construct.xml @@ -34,12 +34,12 @@ callback. - It is valid to install a child watcher after an - EvChild has exited but before the event loop has - started its next iteration(for example, first you fork, then the new child - process might exit, and only then do you install an - EvChild watcher in the parent for the new - PID). + It is valid to install a child watcher after an + EvChild has exited but before the event loop has + started its next iteration. For example, first one calls + fork, then the new child process might exit, and only + then an EvChild watcher is installed in the parent + for the new PID. You can access both exit/tracing status and pid by @@ -47,11 +47,11 @@ properties of the watcher object. - You can have as many PID watchers per - PID as you want, they will all be called. + The number of PID watchers per + PID is unlimited. All of them will be called. - The EvChild::createStopped method doesn't + The EvChild::createStopped method doesn't start(activate) the newly created watcher. diff --git a/reference/ev/evembed/construct.xml b/reference/ev/evembed/construct.xml index 98511827d1..cbc56964d8 100644 --- a/reference/ev/evembed/construct.xml +++ b/reference/ev/evembed/construct.xml @@ -17,7 +17,7 @@ intpriority - This is a rather advanced watcher type that lets you embed one event loop + This is a rather advanced watcher type that lets to embed one event loop into another(currently only IO events are supported in the embedded loop, other types of watchers might be handled in a delayed or incorrect fashion and must not be used). diff --git a/reference/ev/evidle.xml b/reference/ev/evidle.xml index 35ef5cb6dc..d8c2570ce0 100644 --- a/reference/ev/evidle.xml +++ b/reference/ev/evidle.xml @@ -19,15 +19,15 @@ events). - Thus, as long as your process is busy handling sockets or timeouts(or even + Thus, as long as the process is busy handling sockets or timeouts(or even signals) of the same or higher priority it will not be triggered. But when - your process is in idle(or only lower-priority watchers are pending), the + the process is in idle(or only lower-priority watchers are pending), the EvIdle watchers are being called once per event loop - iteration - until stopped, that is, or your process receives more events + iteration - until stopped, that is, or the process receives more events and becomes busy again with higher priority stuff. - Apart from keeping your process non-blocking(which is a useful on its own + Apart from keeping the process non-blocking(which is a useful on its own sometimes), EvIdle watchers are a good place to do "pseudo-background processing", or delay processing stuff to after the event loop has handled all outstanding events. diff --git a/reference/ev/evio.xml b/reference/ev/evio.xml index 886f4aee67..9627a72a34 100644 --- a/reference/ev/evio.xml +++ b/reference/ev/evio.xml @@ -13,21 +13,22 @@ &reftitle.intro; EvIo watchers check whether a file descriptor(or - socket, or a stream castable to numeric file descriptor) is readable or writable in each - iteration of the event loop, or, more precisely, when reading would not - block the process and writing would at least be able to write some data. - This behaviour is called level-triggering because you keep receiving events - as long as the condition persists. Remember, you can stop the watcher if you - don't want to act on the event and neither want to receive future events. + socket, or a stream castable to numeric file descriptor) is readable or + writable in each iteration of the event loop, or, more precisely, when + reading would not block the process and writing would at least be able to + write some data. This behaviour is called + level-triggering because events are kept receiving as + long as the condition persists. To stop receiving events just stop the + watcher. - You can register as many read and/or write event watchers per fd as - you want. Setting all file descriptors to non-blocking mode is also usually a - good idea(but not required). + The number of read and/or write event watchers per fd is + unlimited. Setting all file descriptors to non-blocking mode is also + usually a good idea(but not required). - Another thing you have to watch out for is that it is quite easy to receive - false readiness notifications, i.e. your callback might be called with + Another thing to watch out for is that it is quite easy to receive + false readiness notifications, i.e. the callback might be called with Ev::READ but a subsequent read() will actually block because there is no data. It is very easy to get into this situation. Thus it is best to always use non-blocking I/O: An extra @@ -35,10 +36,11 @@ is far preferable to a program hanging until some data arrives. - If you cannot run the fd in non-blocking mode, then - you have to separately re-test whether a file descriptor is really ready. - Some people additionally use SIGALRM and an interval - timer, just to be sure thry won't block infinitely. + If for some reason it is impossible to run the fd in + non-blocking mode, then separately re-test whether a file + descriptor is really ready. Some people additionally use + SIGALRM and an interval timer, just to be sure thry + won't block infinitely. Always consider using non-blocking mode. diff --git a/reference/ev/evloop.xml b/reference/ev/evloop.xml index d918561057..79ca763e79 100644 --- a/reference/ev/evloop.xml +++ b/reference/ev/evloop.xml @@ -17,13 +17,15 @@ handle EvChild watchers. - If you are creating threads, you have to create a loop per thread, and use + Having threads we have to create a loop per thread, and use the the default loop in the parent thread. - The default event loop is initialized - automatically for you by Ev. You can access it by - means of methods of Ev class, or access the loop - itself via EvLoop::defaultLoop method. + + The default event loop is initialized + automatically by Ev. It is accessable via methods of + the Ev class, or via + EvLoop::defaultLoop method. +
@@ -131,9 +133,9 @@ io_interval - By setting a higher io_interval you allow + Higher io_interval allows libev to spend more time collecting - EvIo events, so you can handle more events per + EvIo events, so more events can be handled per iteration, at the cost of increasing latency. Timeouts (both EvPeriodic and EvTimer) will not be affected. Setting this to a non-zero value will introduce an @@ -145,11 +147,9 @@ which is often enough for interactive servers(not for games). It usually doesn't make much sense to set it to a lower value than 0.01, as this approaches the timing granularity of - most systems. Note that if you do transactions with the outside world - and you can’t increase the parallelism, then this setting will limit - your transaction rate (if you need to poll once per transaction and the - io_interval is 0.01, then you - can't do more than 100 transactions per second). + most systems. + + See also FUNCTIONS CONTROLLING EVENT LOOPS. @@ -160,7 +160,7 @@ timeout_interval - By setting a higher timeout_interval you allow libev + Higher timeout_interval allows libev to spend more time collecting timeouts, at the expense of increased latency/jitter/inexactness(the watcher callback will be called later). EvIo watchers will not be affected. Setting this to a non-null value diff --git a/reference/ev/evperiodic.xml b/reference/ev/evperiodic.xml index a1a25ed1b9..ae904f5762 100644 --- a/reference/ev/evperiodic.xml +++ b/reference/ev/evperiodic.xml @@ -20,20 +20,20 @@ watchers are not based on real time(or relative time, the physical time that passes) but on wall clock time(absolute time, calendar or clock). The difference is that wall clock time can run faster or slower than real time, - and time jumps are not uncommon(e.g. when you adjust it). + and time jumps are not uncommon(e.g. when adjusting it). - You can tell a EvPeriodic watcher to trigger after - some specific point in time: for example, if you tell a - EvPeriodic watcher to trigger "in 10 - seconds" (by specifying e.g. - EvLoop::now + 10.0, that - is, an absolute time not a delay) and then reset your system clock to - January of the previous year, then it will take a year + EvPeriodic watcher can be configured to trigger + after some specific point in time. For example, if an + EvPeriodic watcher is configured to trigger + "in 10 seconds" (e.g. + EvLoop::now + 10.0, i.e. an + absolute time, not a delay), and the system clock is reset to + January of the previous year, then it will take a year or more to trigger the event (unlike an EvTimer, which would still trigger roughly 10 seconds after - starting it, as it uses a relative timeout). + starting it as it uses a relative timeout). diff --git a/reference/ev/evperiodic/again.xml b/reference/ev/evperiodic/again.xml index fcd7fdf13f..04a6ac7266 100644 --- a/reference/ev/evperiodic/again.xml +++ b/reference/ev/evperiodic/again.xml @@ -15,7 +15,7 @@ Simply stops and restarts the periodic watcher again. This is only useful - when you changed some attributes. + when attributes are changed. diff --git a/reference/ev/evperiodic/construct.xml b/reference/ev/evperiodic/construct.xml index e09c929a1b..daa47dddb8 100644 --- a/reference/ev/evperiodic/construct.xml +++ b/reference/ev/evperiodic/construct.xml @@ -21,9 +21,9 @@ choice="opt">intpriority0 - Constructs EvPeriodic watcher object and starts it automatically. If you - need a stopped watcher consider using - EvPeriodic::createStopped method. + Constructs EvPeriodic watcher object and starts it automatically. + EvPeriodic::createStopped method creates stopped + periodic watcher. diff --git a/reference/ev/evsignal.xml b/reference/ev/evsignal.xml index e4c698978c..8d483ddab0 100644 --- a/reference/ev/evsignal.xml +++ b/reference/ev/evsignal.xml @@ -19,22 +19,21 @@ - You can configure as many watchers as you like for the same signal, but - only within the same loop, i.e. you can watch for - SIGINT in the default loop and for - SIGIO in another loop, but you cannot watch for - SIGINT in both the default loop and another loop at - the same time. At the moment, SIGCHLD is permanently - tied to the default loop. + There is no limit for the number of watchers for the same signal, but only + within the same loop, i.e. one can watch for SIGINT in + the default loop and for SIGIO in another loop, but + it is not allowed to watch for SIGINT in both the default loop + and another loop at the same time. At the moment, + SIGCHLD is permanently tied to the default loop. If possible and supported, libev will install its handlers with SA_RESTART (or equivalent) behaviour - enabled, so system calls should not be unduly interrupted. If you have a - problem with system calls getting interrupted by signals you can block all - signals in an EvCheck watcher and unblock them in a - EvPrepare watcher. + enabled, so system calls should not be unduly interrupted. In case of a + problem with system calls getting interrupted by signals, all the + signals can be blocked in an EvCheck watcher and + unblocked in a EvPrepare watcher. @@ -87,7 +86,7 @@ signum - Signal number. You can use constants exported by + Signal number. See the constants exported by pcntl extension. See also signal(7) man page. diff --git a/reference/ev/evsignal/construct.xml b/reference/ev/evsignal/construct.xml index 04508f9cc0..dd9c10014a 100644 --- a/reference/ev/evsignal/construct.xml +++ b/reference/ev/evsignal/construct.xml @@ -19,8 +19,9 @@ choice="opt">intpriority0 - Constructs EvPeriodic watcher object. If you need a stopped watcher, - consider using EvSignal::createStopped. + Constructs EvPeriodic watcher object and starts it automatically. For a + stopped periodic watcher consider using + EvSignal::createStopped method. @@ -32,7 +33,7 @@ signum - Signal number. You can use one exported by pcntl + Signal number. See constants exported by pcntl extension. See also signal(7) man page. diff --git a/reference/ev/evsignal/createstopped.xml b/reference/ev/evsignal/createstopped.xml index c8076a0bfd..67e88a2129 100644 --- a/reference/ev/evsignal/createstopped.xml +++ b/reference/ev/evsignal/createstopped.xml @@ -34,7 +34,7 @@ signum - Signal number. You can use one exported by pcntl + Signal number. See constants exported by pcntl extension. See also signal(7) man page. diff --git a/reference/ev/evstat.xml b/reference/ev/evstat.xml index a5083007e5..37ef3ddd1b 100644 --- a/reference/ev/evstat.xml +++ b/reference/ev/evstat.xml @@ -28,17 +28,17 @@ The path must not end in a slash or contain special components such as '.' or ... The path should be - absolute: if it is relative and your working directory changes, then the + absolute: if it is relative and the working directory changes, then the behaviour is undefined. Since there is no portable change notification interface available, the portable implementation simply calls stat() regularly - on the path to see if it changed somehow. You can specify a recommended - polling interval for this case. If you specify a polling interval of + on the path to see if it changed somehow. For this case a recommended + polling interval can be specified. If one specifies a polling interval of 0.0 (highly recommended) then a suitable, unspecified - default value will be used(which you can expect to be around five seconds, + default value will be used(which could be expected to be around 5 seconds, although this might change dynamically). libev will also impose a minimum interval which is currently around 0.1, but that’s usually overkill. diff --git a/reference/ev/evtimer.xml b/reference/ev/evtimer.xml index a77ac6d5ef..faf88f9afe 100644 --- a/reference/ev/evtimer.xml +++ b/reference/ev/evtimer.xml @@ -18,8 +18,8 @@ - The timers are based on real time, that is, if you register an event that - times out after an hour and you reset your system clock to + The timers are based on real time, that is, if one registers an event that + times out after an hour and resets the system clock to January last year, it will still time out after(roughly) one hour. "Roughly" because detecting time jumps is hard, and some inaccuracies are unavoidable. @@ -36,11 +36,11 @@ - The timer itself will do a best-effort at avoiding drift, that is, if you - configure a timer to trigger every 10 seconds, then it + The timer itself will do a best-effort at avoiding drift, that is, if a + timer is configured to trigger every 10 seconds, then it will normally trigger at exactly 10 second intervals. - If, however, your program cannot keep up with the timer because it takes - longer than those 10 seconds to do stuff) the timer + If, however, the script cannot keep up with the timer because it takes + longer than those 10 seconds to do) the timer will not fire more than once per event loop iteration. diff --git a/reference/ev/evwatcher.xml b/reference/ev/evwatcher.xml index 172669ab0c..c8315e7dbb 100644 --- a/reference/ev/evwatcher.xml +++ b/reference/ev/evwatcher.xml @@ -15,7 +15,7 @@ EvWatcher is a base class for all watchers(EvCheck, EvChild etc.). Since EvWatcher's constructor is - abstract, you can't(and don't need to) create + abstract, one can't(and don't need to) create EvWatcher objects directly. @@ -85,20 +85,22 @@ Readonly.&true; if the watcher is pending, i.e. it has outstanding events, but its callback has not yet been invoked. - &false; otherwise. As long, as a watcher is pending(but not active), you + &false; otherwise. As long, as a watcher is pending(but not active), one must not change its priority. priority - Integer between Ev::MINPRI and + + Integer between Ev::MINPRI and Ev::MAXPRI. Pending watchers with higher priority will be invoked before watchers with lower priority, but priority will not keep watchers from being executed(except for - EvIdle watchers). If you need to suppress - invocation when higher priority events are pending you need to look at - EvIdle watchers, which provide this functionality. + EvIdle watchers). EvIdle + watchers provide functionality to suppress invocation when higher + priority events are pending. + diff --git a/reference/ev/evwatcher/keepalive.xml b/reference/ev/evwatcher/keepalive.xml index 5a19092da4..c5a057a5d2 100644 --- a/reference/ev/evwatcher/keepalive.xml +++ b/reference/ev/evwatcher/keepalive.xml @@ -14,20 +14,19 @@ boolvalue - Configures whether to keep the loop from returning. If you set keepalive - value to &false;, then even though your watcher is - active, it won't keep Ev::run or - EvLoop::run from returning. + Configures whether to keep the loop from returning. With keepalive + value set to &false; the watcher won't keep + Ev::run/EvLoop::run from + returning even though the watcher is active. Watchers have keepalive value &true; by default. - Clearing keepalive status may be useful in cases when you wouldn't want - to keep - Ev::run/EvLoop::run from - returning just because of the(possibly long running watcher - a socket - watcher etc.) + Clearing keepalive status is useful when returning from + Ev::run/EvLoop::run + just because of the watcher is undesirable. It could be a long running UDP socket + watcher or so. @@ -39,10 +38,10 @@ value - If you set keepalive - value to &false;, then even though your watcher is - active, it won't keep Ev::run or - EvLoop::run from returning. + With keepalive value set to &false; the watcher + won't keep + Ev::run/EvLoop::run + from returning even though the watcher is active. diff --git a/reference/ev/periodic-modes.xml b/reference/ev/periodic-modes.xml index 3ef9ba2a98..512ba34408 100644 --- a/reference/ev/periodic-modes.xml +++ b/reference/ev/periodic-modes.xml @@ -59,11 +59,11 @@ $hourly = EvPeriodic(0, 3600, NULL, function () { with the watcher as first, and the current time as second argument. - This callback must not stop or destroy this or any other - periodic watchers, ever, and must not call any event loop - functions or methods. If you need to stop it, return 1e30 - and stop it afterwards. You may create and start a - EvPrepare watcher for this task. + This callback must not stop or destroy this or any other + periodic watchers, ever, and must not call any event loop + functions or methods. To stop it return 1e30 + and stop it afterwards. An EvPrepare watcher may be + used for this task. It must return the next time to trigger, based on the passed time value (that @@ -81,12 +81,12 @@ $hourly = EvPeriodic(0, 3600, NULL, function () { function reschedule_cb ($watcher, $now) { return $now + (10.5. - fmod($now, 10.5)); - } $w = new EvPeriodic(0., 0., "reschedule_cb", function ($w, $revents) { echo time(), PHP_EOL; }); + Ev::run(); ?> ]]> diff --git a/reference/ev/watcher-callbacks.xml b/reference/ev/watcher-callbacks.xml index 3aa56ef121..4b7e93128e 100644 --- a/reference/ev/watcher-callbacks.xml +++ b/reference/ev/watcher-callbacks.xml @@ -50,7 +50,7 @@ Each watcher type has its associated bit in revents, - so you can use the same callback for multiple watchers. The event mask is + so one can use the same callback for multiple watchers. The event mask is named after the type, i.e. EvChild(or EvLoop::child) sets EV::CHILD, EvPrepare(or EvLoop::prepare) diff --git a/reference/ev/watchers.xml b/reference/ev/watchers.xml index 4b1b7842ae..91fe20be94 100644 --- a/reference/ev/watchers.xml +++ b/reference/ev/watchers.xml @@ -3,10 +3,9 @@ Watchers - A watcher is an object that gets created to record your interest in some - event. For instance, if you want to wait for STDIN to - become readable, you would create an EvIo watcher for - that: + A watcher is an object that gets created to record interest in some event. + For instance, the following code waits for STDIN to + become readable: - All the watcher constructors automatically start the watchers for you. If you - need to create a stopped watcher, use createStopped - method(e.g. EvIo::createStopped) + All the watcher constructors automatically start the watchers. + createStopped methods create stopped watchers(e.g. + EvIo::createStopped) Note that a watcher will automatically be stopped when the watcher object is - destroyed, so you need to keep the watcher objects returned by the - constructors or factory methods. + destroyed. Therefore, the watcher objects returned by the + constructors or factory methods should be kept.