sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-16 00:48:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Del: 'you' word

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@328909 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Ruslan Osmanov 2012-12-27 16:33:36 +00:00
parent c0795d6106
commit cb1dd13235
27 changed files with 176 additions and 168 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
reference/ev/book.xml
View file

@ -16,17 +16,24 @@
&note.no-windows.extension;
<para>
<emphasis>Libev</emphasis> 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
<emphasis>Libev</emphasis> 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.
</para>
<para>
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.
</para>
<para>
You register interest in certain events by registering so-called event
watchers, and then hand it over to libev by starting the watcher.
</para>
<para>
For details refer to the <link
xlink:href="http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod">documentation
of libev</link>

40
reference/ev/ev.xml
View file

@ -282,7 +282,7 @@
<methodname>EvLoop::fork</methodname> manually.
This works by calling <literal>getpid()</literal> 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</link>)
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.
<literal>Signalfd</literal> will not be used by default.
</para>
</listitem>
@ -330,12 +329,12 @@
<listitem>
<para>
When this flag is specified, <literal>libev</literal> 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
<literal>libev</literal> unblocking the signals.
modify the signal mask. Specifically, this means having to make sure
signals are unblocked before receiving them.
</para>
<para>
This behaviour is useful for custom signal handling, or handling signals
only in specific threads.
</para>
</listitem>
</varlistentry>
@ -351,7 +350,7 @@
<listitem>
<para>
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 @@
<para>
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 @@
<para>
<literal>kqueue</literal> backend used on most BSD systems.
<classname>EvEmbed</classname> 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 <literal>kqueue</literal> backend and use it
for sockets only.
</para>
@ -648,7 +647,7 @@
<listitem>
<para>
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.
<constant>Ev::BACKEND_ALL</constant> &amp;
~<constant>Ev::BACKEND_KQUEUE</constant>)
Use <methodname>Ev::recommendedBackends</methodname>, or don't specify any
@ -661,10 +660,9 @@
<term><constant>Ev::BACKEND_MASK</constant></term>
<listitem>
<para>
Not a backend, but a mask to select all backend bits from a
<parameter>flags</parameter> value, in case you want to mask out any
backends from a flags value (e.g. when modifying the
<varname>LIBEV_FLAGS</varname> environment variable).
Not a backend, but a mask to select all backend bits from
<parameter>flags</parameter> value to mask out any backends(e.g. when
modifying the <varname>LIBEV_FLAGS</varname> environment variable).
</para>
</listitem>
</varlistentry>
@ -687,9 +685,9 @@
loop</emphasis> in <classname>Ev</classname> class(e.g.
<methodname>Ev::iteration</methodname>, <methodname>Ev::depth</methodname>
etc.) For <emphasis>custom loops</emphasis>(created with
<methodname>EvLoop::__construct</methodname>) you can access these values
via corresponding properties and methods of the <classname>EvLoop</classname>
class.
<methodname>EvLoop::__construct</methodname>) these values may be accessed
via corresponding properties and methods of the
<classname>EvLoop</classname> class.
</para>
<para>

2
reference/ev/ev/feedsignal.xml
View file

@ -16,7 +16,7 @@
<para>
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.
</para>
<para>
Unlike <methodname>Ev::feedSignalEvent</methodname>, this works regardless

2
reference/ev/ev/feedsignalevent.xml
View file

@ -29,7 +29,7 @@
<listitem>
<para>
Signal number. See <literal>signal(7)</literal> man page for detals.
You can use constants exported by <literal>pcntl</literal> extension.
See also constants exported by <literal>pcntl</literal> extension.
</para>
</listitem>
</varlistentry>

6
reference/ev/ev/recommendedbackends.xml
View file

@ -20,9 +20,9 @@
will work for most file descriptor types. This set is often smaller than the
one returned by <function>ev_supported_backends</function>, as for example
<literal>kqueue</literal> is broken on most <literal>BSD</literal> systems
and will not be auto-detected unless you explicitly request it. This is the
set of backends that <literal>libev</literal> 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 <literal>libev</literal> will probe no backends
specified explicitly.
</para>
</refsect1>

9
reference/ev/ev/resume.xml
View file

@ -27,10 +27,11 @@
</para>
<para>
After calling <methodname>Ev::suspend</methodname> you must not call any
function on the given loop other than <methodname>Ev::resume</methodname>,
and you must not call <methodname>Ev::resume</methodname>
without a previous call to <methodname>Ev::suspend</methodname>.
After calling <methodname>Ev::suspend</methodname> it is not allowed to call
any function on the given loop other than
<methodname>Ev::resume</methodname>. Also it is not allowed to call
<methodname>Ev::resume</methodname> without a previous call to
<methodname>Ev::suspend</methodname>.
</para>
<para>

9
reference/ev/ev/suspend.xml
View file

@ -28,10 +28,11 @@
</para>
<para>
After calling <methodname>Ev::suspend</methodname> you must not call any
function on the given loop other than <methodname>Ev::resume</methodname>,
and you must not call <methodname>Ev::resume</methodname>
without a previous call to <methodname>Ev::suspend</methodname>.
After calling <methodname>Ev::suspend</methodname> it is not allowed to call
any function on the given loop other than
<methodname>Ev::resume</methodname>. Also it is not allowed to call
<methodname>Ev::resume</methodname> without a previous call to
<methodname>Ev::suspend</methodname>.
</para>
</refsect1>

19
reference/ev/evcheck.xml
View file

@ -18,23 +18,22 @@
<classname>EvCheck</classname> afterwards.
</para>
<para>
You must not call <methodname>EvLoop::run</methodname> or similar methods
It is not allowed to call <methodname>EvLoop::run</methodname> or similar methods
or functions that enter the current event loop from either
<classname>EvPrepare</classname> or
<classname>EvCheck</classname> 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:
<classname>EvPrepare</classname> or <classname>EvCheck</classname>
watchers. Other loops than the current one are fine, however. The
rationale behind this is that one don&apos;t need to check for recursion
in those watchers, i.e. the sequence will always be:
<classname>EvPrepare</classname> -&gt; blocking -&gt;
<classname>EvCheck</classname>, so if you have one watcher of each kind they will always be called
in pairs bracketing the blocking
call.
<classname>EvCheck</classname>, so having a watcher of each kind they will
always be called in pairs bracketing the blocking call.
</para>
<para>
The main purpose is to integrate other event mechanisms into
<emphasis>libev</emphasis> 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.
</para>
<para>

4
reference/ev/evchild.xml
View file

@ -12,9 +12,9 @@
<section xml:id="evchild.intro">
&reftitle.intro;
<para>
<classname>EvChild</classname> watchers trigger when your process receives
<classname>EvChild</classname> watchers trigger when the process receives
a <constant>SIGCHLD</constant> 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 <constant>EvChild</constant> 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

18
reference/ev/evchild/construct.xml
View file

@ -34,12 +34,12 @@
callback.
</para>
<para>
It is valid to install a child watcher after an
<classname>EvChild</classname> 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
<classname>EvChild</classname> watcher in the parent for the new
<emphasis>PID</emphasis>).
It is valid to install a child watcher after an
<classname>EvChild</classname> has exited but before the event loop has
started its next iteration. For example, first one calls
<literal>fork</literal>, then the new child process might exit, and only
then an <classname>EvChild</classname> watcher is installed in the parent
for the new <emphasis>PID</emphasis>.
</para>
<para>
You can access both exit/tracing status and <parameter>pid</parameter> by
@ -47,11 +47,11 @@
properties of the watcher object.
</para>
<para>
You can have as many <emphasis>PID</emphasis> watchers per
<emphasis>PID</emphasis> as you want, they will all be called.
The number of <emphasis>PID</emphasis> watchers per
<emphasis>PID</emphasis> is unlimited. All of them will be called.
</para>
<para>
The <methodname>EvChild::createStopped</methodname> method doesn't
The <methodname>EvChild::createStopped</methodname> method doesn&apos;t
start(activate) the newly created watcher.
</para>

2
reference/ev/evembed/construct.xml
View file

@ -17,7 +17,7 @@
<methodparam choice="opt"><type>int</type><parameter>priority</parameter></methodparam>
</methodsynopsis>
<para>
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).

8
reference/ev/evidle.xml
View file

@ -19,15 +19,15 @@
<emphasis>events</emphasis>).
</para>
<para>
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
<classname>EvIdle</classname> 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.
</para>
<para>
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), <classname>EvIdle</classname> watchers are a good place to do
<emphasis>"pseudo-background processing"</emphasis>, or delay processing
stuff to after the event loop has handled all outstanding events.

32
reference/ev/evio.xml
View file

@ -13,21 +13,22 @@
&reftitle.intro;
<para>
<classname>EvIo</classname> 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 <emphasis>level-triggering</emphasis> 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
<emphasis>level-triggering</emphasis> because events are kept receiving as
long as the condition persists. To stop receiving events just stop the
watcher.
</para>
<para>
You can register as many read and/or write event watchers per <parameter>fd</parameter> 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 <parameter>fd</parameter> is
unlimited. Setting all file descriptors to non-blocking mode is also
usually a good idea(but not required).
</para>
<para>
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
<constant>Ev::READ</constant> but a subsequent <emphasis>read()</emphasis>
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.
</para>
<para>
If you cannot run the <parameter>fd</parameter> in non-blocking mode, then
you have to separately re-test whether a file descriptor is really ready.
Some people additionally use <constant>SIGALRM</constant> and an interval
timer, just to be sure thry won't block infinitely.
If for some reason it is impossible to run the <parameter>fd</parameter> in
non-blocking mode, then separately re-test whether a file
descriptor is really ready. Some people additionally use
<constant>SIGALRM</constant> and an interval timer, just to be sure thry
won't block infinitely.
</para>
<para>
Always consider using non-blocking mode.

26
reference/ev/evloop.xml
View file

@ -17,13 +17,15 @@
handle <classname>EvChild</classname> watchers.
</para>
<para>
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 <emphasis>the default loop</emphasis> in the parent thread.
</para>
<para>The <emphasis>default event loop</emphasis> is initialized
automatically for you by <emphasis>Ev</emphasis>. You can access it by
means of methods of <classname>Ev</classname> class, or access the loop
itself via <methodname>EvLoop::defaultLoop</methodname> method.</para>
<para>
The <emphasis>default event loop</emphasis> is initialized
automatically by <emphasis>Ev</emphasis>. It is accessable via methods of
the <classname>Ev</classname> class, or via
<methodname>EvLoop::defaultLoop</methodname> method.
</para>
</section>
<!-- }}} -->
@ -131,9 +133,9 @@
<term><varname>io_interval</varname></term>
<listitem>
<para>
By setting a higher <varname>io_interval</varname> you allow
Higher <varname>io_interval</varname> allows
<emphasis>libev</emphasis> to spend more time collecting
<classname>EvIo</classname> events, so you can handle more events per
<classname>EvIo</classname> events, so more events can be handled per
iteration, at the cost of increasing latency. Timeouts (both
<classname>EvPeriodic</classname> and <classname>EvTimer</classname>)
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
<constant>0.01</constant>, 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
<varname>io_interval</varname> is <constant>0.01</constant>, then you
can't do more than <constant>100</constant> transactions per second).
most systems.
</para>
<para>
See also <link
xlink:href="http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#FUNCTIONS_CONTROLLING_EVENT_LOOPS">FUNCTIONS
CONTROLLING EVENT LOOPS</link>.
@ -160,7 +160,7 @@
<term><varname>timeout_interval</varname></term>
<listitem>
<para>
By setting a higher <varname>timeout_interval</varname> you allow <emphasis>libev</emphasis>
Higher <varname>timeout_interval</varname> allows <emphasis>libev</emphasis>
to spend more time collecting timeouts, at the expense of increased
latency/jitter/inexactness(the watcher callback will be called later).
<classname>EvIo</classname> watchers will not be affected. Setting this to a non-null value

18
reference/ev/evperiodic.xml
View file

@ -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).
</para>
<para>
You can tell a <classname>EvPeriodic</classname> watcher to trigger after
some specific point in time: for example, if you tell a
<classname>EvPeriodic</classname> watcher to trigger <emphasis>"in 10
seconds"</emphasis> (by specifying e.g.
<methodname>EvLoop::now</methodname> + <constant>10.0</constant>, that
is, an absolute time not a delay) and then reset your system clock to
<emphasis>January</emphasis> of the previous year, then it will take a year
<classname>EvPeriodic</classname> watcher can be configured to trigger
after some specific point in time. For example, if an
<classname>EvPeriodic</classname> watcher is configured to trigger
<emphasis>"in 10 seconds"</emphasis> (e.g.
<methodname>EvLoop::now</methodname> + <constant>10.0</constant>, i.e. an
absolute time, not a delay), and the system clock is reset to
<emphasis>January of the previous year</emphasis>, then it will take a year
or more to trigger the event (unlike an <classname>EvTimer</classname>,
which would still trigger roughly <constant>10</constant> seconds after
starting it, as it uses a relative timeout).
starting it as it uses a relative timeout).
</para>
<para>

2
reference/ev/evperiodic/again.xml
View file

@ -15,7 +15,7 @@
</methodsynopsis>
<para>
Simply stops and restarts the periodic watcher again. This is only useful
when you changed some attributes.
when attributes are changed.
</para>
</refsect1>

6
reference/ev/evperiodic/construct.xml
View file

@ -21,9 +21,9 @@
choice="opt"><type>int</type><parameter>priority</parameter><initializer>0</initializer></methodparam>
</methodsynopsis>
<para>
Constructs EvPeriodic watcher object and starts it automatically. If you
need a stopped watcher consider using
<methodname>EvPeriodic::createStopped</methodname> method.
Constructs EvPeriodic watcher object and starts it automatically.
<methodname>EvPeriodic::createStopped</methodname> method creates stopped
periodic watcher.
</para>
</refsect1>

23
reference/ev/evsignal.xml
View file

@ -19,22 +19,21 @@
</para>
<para>
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
<constant>SIGINT</constant> in the default loop and for
<constant>SIGIO</constant> in another loop, but you cannot watch for
<constant>SIGINT</constant> in both the default loop and another loop at
the same time. At the moment, <constant>SIGCHLD</constant> 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 <constant>SIGINT</constant> in
the default loop and for <constant>SIGIO</constant> in another loop, but
it is not allowed to watch for <constant>SIGINT</constant> in both the default loop
and another loop at the same time. At the moment,
<constant>SIGCHLD</constant> is permanently tied to the default loop.
</para>
<para>
If possible and supported, <emphasis>libev</emphasis> will install its
handlers with <literal>SA_RESTART</literal> (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 <classname>EvCheck</classname> watcher and unblock them in a
<classname>EvPrepare</classname> 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 <classname>EvCheck</classname> watcher and
unblocked in a <classname>EvPrepare</classname> watcher.
</para>
</section>
@ -87,7 +86,7 @@
<varlistentry xml:id="evsignal.props.signum">
<term><varname>signum</varname></term>
<listitem>
<para>Signal number. You can use constants exported by
<para>Signal number. See the constants exported by
<emphasis>pcntl</emphasis> extension. See also
<literal>signal(7)</literal> man page.
</para>

7
reference/ev/evsignal/construct.xml
View file

@ -19,8 +19,9 @@
choice="opt"><type>int</type><parameter>priority</parameter><initializer>0</initializer></methodparam>
</methodsynopsis>
<para>
Constructs EvPeriodic watcher object. If you need a stopped watcher,
consider using <methodname>EvSignal::createStopped</methodname>.
Constructs EvPeriodic watcher object and starts it automatically. For a
stopped periodic watcher consider using
<methodname>EvSignal::createStopped</methodname> method.
</para>
</refsect1>
@ -32,7 +33,7 @@
<term><parameter>signum</parameter></term>
<listitem>
<para>
Signal number. You can use one exported by <emphasis>pcntl</emphasis>
Signal number. See constants exported by <emphasis>pcntl</emphasis>
extension. See also <literal>signal(7)</literal> man page.
</para>
</listitem>

2
reference/ev/evsignal/createstopped.xml
View file

@ -34,7 +34,7 @@
<term><parameter>signum</parameter></term>
<listitem>
<para>
Signal number. You can use one exported by <emphasis>pcntl</emphasis>
Signal number. See constants exported by <emphasis>pcntl</emphasis>
extension. See also <literal>signal(7)</literal> man page.
</para>
</listitem>

8
reference/ev/evstat.xml
View file

@ -28,17 +28,17 @@
<para>
The path must not end in a slash or contain special components such as
<constant>'.'</constant> or <constant>..</constant>. 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.
</para>
<para>
Since there is no portable change notification interface available, the
portable implementation simply calls <emphasis>stat()</emphasis> 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
<constant>0.0 </constant>(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). <emphasis>libev</emphasis> will
also impose a minimum interval which is currently around
<constant>0.1</constant>, but that’s usually overkill.

12
reference/ev/evtimer.xml
View file

@ -18,8 +18,8 @@
</para>
<para>
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
<emphasis>January last year</emphasis>, 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 @@
</para>
<para>
The timer itself will do a best-effort at avoiding drift, that is, if you
configure a timer to trigger every <constant>10</constant> seconds, then it
The timer itself will do a best-effort at avoiding drift, that is, if a
timer is configured to trigger every <constant>10</constant> seconds, then it
will normally trigger at exactly <constant>10</constant> second intervals.
If, however, your program cannot keep up with the timer because it takes
longer than those <constant>10</constant> seconds to do stuff) the timer
If, however, the script cannot keep up with the timer because it takes
longer than those <constant>10</constant> seconds to do) the timer
will not fire more than once per event loop iteration.
</para>
</section>

14
reference/ev/evwatcher.xml
View file

@ -15,7 +15,7 @@
<classname>EvWatcher</classname> is a base class for all
watchers(<classname>EvCheck</classname>, <classname>EvChild</classname>
etc.). Since <classname>EvWatcher</classname>&apos;s constructor is
<modifier>abstract</modifier>, you can't(and don't need to) create
<modifier>abstract</modifier>, one can&apos;t(and don&apos;t need to) create
EvWatcher objects directly.
</para>
</section>
@ -85,20 +85,22 @@
<listitem>
<para><emphasis>Readonly</emphasis>.&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 <emphasis>not</emphasis> change its priority.</para>
</listitem>
</varlistentry>
<varlistentry xml:id="evwatcher.props.priority">
<term><varname>priority</varname></term>
<listitem>
<para><type>Integer</type> between <constant>Ev::MINPRI</constant> and
<para>
<type>Integer</type> between <constant>Ev::MINPRI</constant> and
<constant>Ev::MAXPRI</constant>. Pending watchers with higher priority
will be invoked before watchers with lower priority, but priority will
not keep watchers from being executed(except for
<classname>EvIdle</classname> watchers). If you need to suppress
invocation when higher priority events are pending you need to look at
<classname>EvIdle</classname> watchers, which provide this functionality.</para>
<classname>EvIdle</classname> watchers). <classname>EvIdle</classname>
watchers provide functionality to suppress invocation when higher
priority events are pending.
</para>
</listitem>
</varlistentry>
</variablelist>

25
reference/ev/evwatcher/keepalive.xml
View file

@ -14,20 +14,19 @@
<methodparam choice="opt"><type>bool</type><parameter>value</parameter></methodparam>
</methodsynopsis>
<para>
Configures whether to keep the loop from returning. If you set keepalive
<parameter>value</parameter> to &false;, then even though your watcher is
active, it won't keep <methodname>Ev::run</methodname> or
<methodname>EvLoop::run</methodname> from returning.
Configures whether to keep the loop from returning. With keepalive
<parameter>value</parameter> set to &false; the watcher won&apos;t keep
<methodname>Ev::run</methodname>/<methodname>EvLoop::run</methodname> from
returning even though the watcher is active.
</para>
<para>
Watchers have keepalive <parameter>value</parameter> &true; by default.
</para>
<para>
Clearing keepalive status may be useful in cases when you wouldn&apos;t want
to keep
<methodname>Ev::run</methodname>/<methodname>EvLoop::run</methodname> from
returning just because of the(possibly long running watcher - a socket
watcher etc.)
Clearing keepalive status is useful when returning from
<methodname>Ev::run</methodname>/<methodname>EvLoop::run</methodname>
just because of the watcher is undesirable. It could be a long running UDP socket
watcher or so.
</para>
</refsect1>
@ -39,10 +38,10 @@
<term><parameter>value</parameter></term>
<listitem>
<para>
If you set keepalive
<parameter>value</parameter> to &false;, then even though your watcher is
active, it won't keep <methodname>Ev::run</methodname> or
<methodname>EvLoop::run</methodname> from returning.
With keepalive <parameter>value</parameter> set to &false; the watcher
won&apos;t keep
<methodname>Ev::run</methodname>/<methodname>EvLoop::run</methodname>
from returning even though the watcher is active.
</para>
</listitem>
</varlistentry>

12
reference/ev/periodic-modes.xml
View file

@ -59,11 +59,11 @@ $hourly = EvPeriodic(0, 3600, NULL, function () {
with the watcher as first, and the current time as second argument.
</para>
<para>
This callback <emphasis>must not</emphasis> stop or destroy this or any other
periodic watchers, ever, and <emphasis>must not</emphasis> call any event loop
functions or methods. If you need to stop it, return <constant>1e30</constant>
and stop it afterwards. You may create and start a
<classname>EvPrepare</classname> watcher for this task.
This callback <emphasis>must not</emphasis> stop or destroy this or any other
periodic watchers, ever, and <emphasis>must not</emphasis> call any event loop
functions or methods. To stop it return <constant>1e30</constant>
and stop it afterwards. An <classname>EvPrepare</classname> watcher may be
used for this task.
</para>
<para>
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();
?>
]]>

2
reference/ev/watcher-callbacks.xml
View file

@ -50,7 +50,7 @@
<para>
Each watcher type has its associated bit in <parameter>revents</parameter>,
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. <classname>EvChild</classname>(or
<methodname>EvLoop::child</methodname>) sets <constant>EV::CHILD</constant>,
<classname>EvPrepare</classname>(or <methodname>EvLoop::prepare</methodname>)

17
reference/ev/watchers.xml
View file

@ -3,10 +3,9 @@
<title>Watchers</title>
<para>
A watcher is an object that gets created to record your interest in some
event. For instance, if you want to wait for <constant>STDIN</constant> to
become readable, you would create an <classname>EvIo</classname> watcher for
that:
A watcher is an object that gets created to record interest in some event.
For instance, the following code waits for <constant>STDIN</constant> to
become readable:
<programlisting role="php">
<![CDATA[
<?php
@ -21,15 +20,15 @@ Ev::run(Ev::RUN_ONCE);
</para>
<para>
All the watcher constructors automatically start the watchers for you. If you
need to create a stopped watcher, use <literal>createStopped</literal>
method(e.g. <methodname>EvIo::createStopped</methodname>)
All the watcher constructors automatically start the watchers.
<literal>createStopped</literal> methods create stopped watchers(e.g.
<methodname>EvIo::createStopped</methodname>)
</para>
<para>
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.
</para>
<para>