diff --git a/Makefile b/Makefile index 1fdd86b8b..fb4a84ff0 100644 --- a/Makefile +++ b/Makefile @@ -2,7 +2,7 @@ test/echo-server: test/echo-server.c ol.a $(CC) -o test/echo-server test/echo-server.c ol.a -lm ol.a: ol-unix.o ev/ev.o - ar rcs ol.a ol-unix.o ev/ev.o + $(AR) rcs ol.a ol-unix.o ev/ev.o ol-unix.o: ol-unix.c ol.h ol-unix.h $(CC) -c ol-unix.c -o ol-unix.o -lm @@ -17,9 +17,9 @@ ev/config.h: .PHONY: clean distclean clean: - rm *.o *.a + $(RM) -f *.o *.a $(MAKE) -C ev clean distclean: - rm *.o *.a + $(RM) -f *.o *.a $(MAKE) -C ev clean diff --git a/iocp-links.html b/iocp-links.html index c45d3c744..da2b8c27b 100644 --- a/iocp-links.html +++ b/iocp-links.html @@ -52,11 +52,9 @@ high-concurrency servers. Instead a system called overlapped I/O is used. I/O - completion ports (IOCP) are the objects used to poll overlapped I/O + completion ports (IOCPs) are the objects used to poll overlapped I/O for completion. - -
-IOCP are similar to the Unix I/O multiplexers +IOCPs are similar to the Unix I/O multiplexers
select(),
- which is available everywhere but is inefficient.
+ which is available everywhere.
send(2)
-on it, as you commonly do in Unix operating systems, with overlapped I/O you
+on it, as you commonly would do in a Unix, with overlapped I/O you
would rather WSASend()
the data and then wait for it to have been sent.
-Unix non-blocking I/O is not beautiful. A major feature of Unix is the -unified treatment of all things as files (or more precisely as file +
Unix non-blocking I/O is not beautiful. A principle abstraction in Unix
+is the unified treatment of many things as files (or more precisely as file
descriptors). write(2), read(2), and
close(2) work with TCP sockets just as they do on regular
files. Well—kind of. Synchronous operations work similarly on different
@@ -121,7 +119,7 @@ file descriptors with a I/O multiplexer—not POSIX AIO.
Common practice for accessing the disk asynchronously is still done using custom
userland thread pools—not POSIX AIO.
-
Windows IOCP does support both sockets and regular file I/O which +
Windows IOCPs does support both sockets and regular file I/O which
greatly simplifies the handling of disks. Although the function names are
not exactly the same in Windows for sockets and regular files, the
they act similar.
@@ -279,7 +277,7 @@ layer but in the author's opinion, none are completely satisfactory.
read(2) calls do not guarantee that they won't block.
Therefore libeio is provided for calling various disk-related
syscalls in a managed thread pool. Unfortunately the abstraction layer
- which libev targets is not appropriate for IOCP—libev works strictly
+ which libev targets is not appropriate for IOCPs—libev works strictly
with file descriptors and does not the concept of a socket.
Furthermore users on Unix will be using libeio for file I/O which is not
ideal for porting to Windows. On windows libev currently uses
@@ -295,14 +293,14 @@ layer but in the author's opinion, none are completely satisfactory.
libevent and rejected it—it's interesting to read his reasons
why. A
- major rewrite was done for version 2 to support Windows IOCP but was done for version 2 to support Windows IOCPs but anecdotal
evidence suggests that it is still not working correctly.
Boost
ASIO. It basically does what you want on Windows and Unix for
- sockets. That is, epoll on Linux, kqueue on Macintosh, IOCP on Windows.
+ sockets. That is, epoll on Linux, kqueue on Macintosh, IOCPs on Windows.
It does not support file I/O. In the author's opinion is it too large
for a not extremely difficult problem (~300 files, ~12000 semicolons).
diff --git a/ol-unix.c b/ol-unix.c
index 0ad0c3256..2b7b769a7 100644
--- a/ol-unix.c
+++ b/ol-unix.c
@@ -3,17 +3,16 @@
#include