summaryrefslogtreecommitdiff
path: root/ev.pod
diff options
context:
space:
mode:
Diffstat (limited to 'ev.pod')
-rw-r--r--ev.pod29
1 files changed, 15 insertions, 14 deletions
diff --git a/ev.pod b/ev.pod
index 532ba49..496d3f4 100644
--- a/ev.pod
+++ b/ev.pod
@@ -3937,6 +3937,9 @@ way (note also that glib is the slowest event library known to man).
There is no supported compilation method available on windows except
embedding it into other applications.
+Sensible signal handling is officially unsupported by Microsoft - libev
+tries its best, but under most conditions, signals will simply not work.
+
Not a libev limitation but worth mentioning: windows apparently doesn't
accept large writes: instead of resulting in a partial write, windows will
either accept everything or return C<ENOBUFS> if the buffer is too large,
@@ -3950,7 +3953,7 @@ is not recommended (and not reasonable). If your program needs to use
more than a hundred or so sockets, then likely it needs to use a totally
different implementation for windows, as libev offers the POSIX readiness
notification model, which cannot be implemented efficiently on windows
-(Microsoft monopoly games).
+(due to Microsoft monopoly games).
A typical way to use libev under windows is to embed it (see the embedding
section for details) and use the following F<evwrap.h> header file instead
@@ -3996,24 +3999,22 @@ Early versions of winsocket's select only supported waiting for a maximum
of C<64> handles (probably owning to the fact that all windows kernels
can only wait for C<64> things at the same time internally; Microsoft
recommends spawning a chain of threads and wait for 63 handles and the
-previous thread in each. Great).
+previous thread in each. Sounds great!).
Newer versions support more handles, but you need to define C<FD_SETSIZE>
to some high number (e.g. C<2048>) before compiling the winsocket select
-call (which might be in libev or elsewhere, for example, perl does its own
-select emulation on windows).
+call (which might be in libev or elsewhere, for example, perl and many
+other interpreters do their own select emulation on windows).
Another limit is the number of file descriptors in the Microsoft runtime
-libraries, which by default is C<64> (there must be a hidden I<64> fetish
-or something like this inside Microsoft). You can increase this by calling
-C<_setmaxstdio>, which can increase this limit to C<2048> (another
-arbitrary limit), but is broken in many versions of the Microsoft runtime
-libraries.
-
-This might get you to about C<512> or C<2048> sockets (depending on
-windows version and/or the phase of the moon). To get more, you need to
-wrap all I/O functions and provide your own fd management, but the cost of
-calling select (O(n²)) will likely make this unworkable.
+libraries, which by default is C<64> (there must be a hidden I<64>
+fetish or something like this inside Microsoft). You can increase this
+by calling C<_setmaxstdio>, which can increase this limit to C<2048>
+(another arbitrary limit), but is broken in many versions of the Microsoft
+runtime libraries. This might get you to about C<512> or C<2048> sockets
+(depending on windows version and/or the phase of the moon). To get more,
+you need to wrap all I/O functions and provide your own fd management, but
+the cost of calling select (O(n²)) will likely make this unworkable.
=back