ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.282 by root, Wed Mar 10 08:19:39 2010 UTC vs.
Revision 1.284 by root, Sun Mar 14 21:05:52 2010 UTC

… …
1538 1538
1539So when you encounter spurious, unexplained daemon exits, make sure you 1539So when you encounter spurious, unexplained daemon exits, make sure you
1540ignore SIGPIPE (and maybe make sure you log the exit status of your daemon 1540ignore SIGPIPE (and maybe make sure you log the exit status of your daemon
1541somewhere, as that would have given you a big clue). 1541somewhere, as that would have given you a big clue).
1542 1542
1543=head3 The special problem of accept()ing when you can't
1544
1545Many implementations of the POSIX C<accept> function (for example,
1546found in port-2004 Linux) have the peculiar behaviour of not removing a
1547connection from the pending queue in all error cases.
1548
1549For example, larger servers often run out of file descriptors (because
1550of resource limits), causing C<accept> to fail with C<ENFILE> but not
1551rejecting the connection, leading to libev signalling readiness on
1552the next iteration again (the connection still exists after all), and
1553typically causing the program to loop at 100% CPU usage.
1554
1555Unfortunately, the set of errors that cause this issue differs between
1556operating systems, there is usually little the app can do to remedy the
1557situation, and no known thread-safe method of removing the connection to
1558cope with overload is known (to me).
1559
1560One of the easiest ways to handle this situation is to just ignore it
1561- when the program encounters an overload, it will just loop until the
1562situation is over. While this is a form of busy waiting, no OS offers an
1563event-based way to handle this situation, so it's the best one can do.
1564
1565A better way to handle the situation is to log any errors other than
1566C<EAGAIN> and C<EWOULDBLOCK>, making sure not to flood the log with such
1567messages, and continue as usual, which at least gives the user an idea of
1568what could be wrong ("raise the ulimit!"). For extra points one could stop
1569the C<ev_io> watcher on the listening fd "for a while", which reduces CPU
1570usage.
1571
1572If your program is single-threaded, then you could also keep a dummy file
1573descriptor for overload situations (e.g. by opening F</dev/null>), and
1574when you run into C<ENFILE> or C<EMFILE>, close it, run C<accept>,
1575close that fd, and create a new dummy fd. This will gracefully refuse
1576clients under typical overload conditions.
1577
1578The last way to handle it is to simply log the error and C<exit>, as
1579is often done with C<malloc> failures, but this results in an easy
1580opportunity for a DoS attack.
1543 1581
1544=head3 Watcher-Specific Functions 1582=head3 Watcher-Specific Functions
1545 1583
1546=over 4 1584=over 4
1547 1585
… …
3838fine. 3876fine.
3839 3877
3840If your embedding application does not need any priorities, defining these 3878If your embedding application does not need any priorities, defining these
3841both to C<0> will save some memory and CPU. 3879both to C<0> will save some memory and CPU.
3842 3880
3843=item EV_PERIODIC_ENABLE 3881=item EV_PERIODIC_ENABLE, EV_IDLE_ENABLE, EV_EMBED_ENABLE, EV_STAT_ENABLE,
3882EV_PREPARE_ENABLE, EV_CHECK_ENABLE, EV_FORK_ENABLE, EV_SIGNAL_ENABLE,
3883EV_ASYNC_ENABLE, EV_CHILD_ENABLE.
3844 3884
3845If undefined or defined to be C<1>, then periodic timers are supported. If 3885If undefined or defined to be C<1> (and the platform supports it), then
3846defined to be C<0>, then they are not. Disabling them saves a few kB of 3886the respective watcher type is supported. If defined to be C<0>, then it
3847code. 3887is not. Disabling watcher types mainly saves codesize.
3848
3849=item EV_IDLE_ENABLE
3850
3851If undefined or defined to be C<1>, then idle watchers are supported. If
3852defined to be C<0>, then they are not. Disabling them saves a few kB of
3853code.
3854
3855=item EV_EMBED_ENABLE
3856
3857If undefined or defined to be C<1>, then embed watchers are supported. If
3858defined to be C<0>, then they are not. Embed watchers rely on most other
3859watcher types, which therefore must not be disabled.
3860
3861=item EV_STAT_ENABLE
3862
3863If undefined or defined to be C<1>, then stat watchers are supported. If
3864defined to be C<0>, then they are not.
3865
3866=item EV_FORK_ENABLE
3867
3868If undefined or defined to be C<1>, then fork watchers are supported. If
3869defined to be C<0>, then they are not.
3870
3871=item EV_SIGNAL_ENABLE
3872
3873If undefined or defined to be C<1>, then signal watchers are supported. If
3874defined to be C<0>, then they are not.
3875
3876=item EV_ASYNC_ENABLE
3877
3878If undefined or defined to be C<1>, then async watchers are supported. If
3879defined to be C<0>, then they are not.
3880
3881=item EV_CHILD_ENABLE
3882
3883If undefined or defined to be C<1> (and C<_WIN32> is not defined), then
3884child watchers are supported. If defined to be C<0>, then they are not.
3885 3888
3886=item EV_MINIMAL 3889=item EV_MINIMAL
3887 3890
3888If you need to shave off some kilobytes of code at the expense of some 3891If you need to shave off some kilobytes of code at the expense of some
3889speed (but with the full API), define this symbol to C<1>. Currently this 3892speed (but with the full API), define this symbol to C<1>. Currently this
… …
3900Defining C<EV_MINIMAL> to C<2> will additionally reduce the core API to 3903Defining C<EV_MINIMAL> to C<2> will additionally reduce the core API to
3901provide a bare-bones event library. See C<ev.h> for details on what parts 3904provide a bare-bones event library. See C<ev.h> for details on what parts
3902of the API are still available, and do not complain if this subset changes 3905of the API are still available, and do not complain if this subset changes
3903over time. 3906over time.
3904 3907
3905This example set of settings reduces the compiled size of libev from 24Kb 3908This example set of settings reduces the compiled size of libev from
3906to 8Kb on my GNU/Linux amd64 system (and leaves little in - there is also 390923.9Kb to 7.7Kb on my GNU/Linux amd64 system (and leaves little
3907an effect on the amount of memory used). With an intelligent-enough linker 3910in - there is also an effect on the amount of memory used). With
3908further unused functions might be left out as well automatically. 3911an intelligent-enough linker (gcc+binutils do this when you use
3912C<-Wl,--gc-sections -ffunction-sections>) further unused functions might
3913be left out as well automatically - a binary starting a timer and an I/O
3914watcher then might come out at only 5Kb.
3909 3915
3910 // tuning and API changes 3916 // tuning and API changes
3911 #define EV_MINIMAL 2 3917 #define EV_MINIMAL 2
3912 #define EV_MULTIPLICITY 0 3918 #define EV_MULTIPLICITY 0
3913 #define EV_MINPRI 0 3919 #define EV_MINPRI 0
… …
3929 3935
3930 // disable all watcher types that cna be disabled 3936 // disable all watcher types that cna be disabled
3931 #define EV_STAT_ENABLE 0 3937 #define EV_STAT_ENABLE 0
3932 #define EV_PERIODIC_ENABLE 0 3938 #define EV_PERIODIC_ENABLE 0
3933 #define EV_IDLE_ENABLE 0 3939 #define EV_IDLE_ENABLE 0
3940 #define EV_CHECK_ENABLE 0
3941 #define EV_PREPARE_ENABLE 0
3934 #define EV_FORK_ENABLE 0 3942 #define EV_FORK_ENABLE 0
3935 #define EV_SIGNAL_ENABLE 0 3943 #define EV_SIGNAL_ENABLE 0
3936 #define EV_CHILD_ENABLE 0 3944 #define EV_CHILD_ENABLE 0
3937 #define EV_ASYNC_ENABLE 0 3945 #define EV_ASYNC_ENABLE 0
3938 #define EV_EMBED_ENABLE 0 3946 #define EV_EMBED_ENABLE 0

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines