Permalink
Browse files

compiles - obviously doesn't work

  • Loading branch information...
1 parent 668c0c6 commit b17dcd55d724cd9c07e35dec2a2bf5f659ce2de4 @ry ry committed Mar 28, 2011
Showing with 63 additions and 25 deletions.
  1. +3 −3 Makefile
  2. +13 −15 iocp-links.html
  3. +44 −6 ol-unix.c
  4. +2 −1 ol.h
  5. +1 −0 test/echo-server.c
View
@@ -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
View
@@ -52,11 +52,9 @@
href="http://msdn.microsoft.com/en-us/library/ms686358(v=vs.85).aspx">overlapped
I/O</a> is used. <a
href="http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx">I/O
- completion ports</a> (IOCP) are the objects used to poll overlapped I/O
+ completion ports</a> (IOCPs) are the objects used to poll overlapped I/O
for completion.
-
-<p>
-IOCP are similar to the Unix I/O multiplexers
+IOCPs are similar to the Unix I/O multiplexers
<ul>
<li> <a
href="http://en.wikipedia.org/wiki/Kqueue">kqueue</a> on Macintosh and
@@ -66,25 +64,25 @@
<li> <a
href="http://developers.sun.com/solaris/articles/event_completion.html">event
completion ports</a> on Solaris,
- <li> <a href="">poll</a> on modern Unixes, or
+ <li> <a href="">poll</a> on modern Unixes, and
<li> <a
href="http://www.kernel.org/doc/man-pages/online/pages/man2/select.2.html"><code>select()</code></a>,
- which is available everywhere but is inefficient.
+ which is available everywhere.
</ul>
-The fundamental variation is that in Unixes you generally ask the kernel to
+The fundamental variation is that in a Unix you generally ask the kernel to
wait for state change in a file descriptor's readability or writablity. With
-overlapped I/O and IOCP the programmers waits for asynchronous function
+overlapped I/O and IOCPs the programmers waits for asynchronous function
calls to complete.
For example, instead of waiting for a socket to become writable and then
using <a
href="http://www.kernel.org/doc/man-pages/online/pages/man2/send.2.html"><code>send(2)</code></a>
-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 <a
href="http://msdn.microsoft.com/en-us/library/ms742203(v=vs.85).aspx"><code>WSASend()</code></a>
the data and then wait for it to have been sent.
-<p> 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
+<p> 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). <code>write(2)</code>, <code>read(2)</code>, and
<code>close(2)</code> work with TCP sockets just as they do on regular
files. Well&mdash;kind of. Synchronous operations work similarly on different
@@ -121,7 +119,7 @@
Common practice for accessing the disk asynchronously is still done using custom
userland thread pools&mdash;not POSIX AIO.
-<p>Windows IOCP does support both sockets and regular file I/O which
+<p>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 @@
<code>read(2)</code> 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&mdash;libev works strictly
+ which libev targets is not appropriate for IOCPs&mdash;libev works strictly
with file descriptors and does not the concept of a <i>socket</i>.
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 @@
libevent and rejected it</a>&mdash;it's interesting to read his reasons
why. <a
href="http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libevent-14x-only.html">A
- major rewrite</a> was done for version 2 to support Windows IOCP but <a
+ major rewrite</a> was done for version 2 to support Windows IOCPs but <a
href="http://www.mail-archive.com/libevent-users@monkey.org/msg01730.html">anecdotal
evidence</a> suggests that it is still not working correctly.
<p><b><a
href="http://www.boost.org/doc/libs/1_43_0/doc/html/boost_asio.html">Boost
ASIO</a>.</b> 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).
View
@@ -3,17 +3,16 @@
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
+#include <string.h> /* strnlen */
void ol_tcp_io(EV_P_ ev_io* watcher, int revents);
void ol_tcp_connect(ol_handle* handle, ol_req* req);
+int ol_close_error(ol_handle* handle, ol_err err);
static int ol_err_new(int e) {
- if (e == 0) {
- return e;
- } else {
- }
+ return e;
}
@@ -28,6 +27,16 @@ struct sockaddr_in ol_ip4_addr(char *ip, int port) {
}
+int ol_close(ol_handle* handle) {
+ return ol_close_error(handle, 0);
+}
+
+
+int ol_run() {
+ ev_run(0);
+}
+
+
ol_handle* ol_handle_new(ol_close_cb close_cb, void* data) {
ol_handle *handle = calloc(sizeof(ol_handle), 1);
handle->close_cb = close_cb;
@@ -65,15 +74,16 @@ int ol_listen(ol_handle* handle, int backlog, ol_accept_cb cb) {
}
-void ol_close_error(ol_handle* handle, ol_err err) {
+int ol_close_error(ol_handle* handle, ol_err err) {
ev_io_stop(&handle->_.read_watcher);
close(handle->_.fd);
handle->_.fd = -1;
-
if (handle->close_cb) {
handle->close_cb(handle, err);
}
+
+ return err;
}
@@ -197,3 +207,31 @@ int ol_connect(ol_handle* handle, ol_req *req_in, struct sockaddr* addr) {
return ol_err_new(r);
}
+int ol_write(ol_handle* handle, ol_req *req, ol_buf* bufs, int bufcnt) {
+ // stub
+ assert(0);
+ return 0;
+}
+
+
+int ol_write2(ol_handle* handle, const char* msg) {
+ size_t len = strnlen(msg, 1024 * 1024);
+ ol_buf b;
+ b.base = (char*)msg;
+ b.len = len;
+ return ol_write(handle, NULL, &b, 1);
+}
+
+
+int ol_read(ol_handle* handle, ol_req *req, ol_buf* bufs, int bufcnt) {
+ // stub
+ assert(0);
+ return 0;
+}
+
+
+void ol_free(ol_handle* handle) {
+ free(handle);
+ // lists?
+ return;
+}
View
3 ol.h
@@ -85,6 +85,7 @@ int ol_listen(ol_handle* handle, int backlog, ol_accept_cb cb);
int ol_connect(ol_handle* handle, ol_req *req, struct sockaddr* addr);
int ol_read(ol_handle* handle, ol_req *req, ol_buf* bufs, int bufcnt);
int ol_write(ol_handle* handle, ol_req *req, ol_buf* bufs, int bufcnt);
+int ol_write2(ol_handle* handle, const char* msg);
int ol_shutdown(ol_handle* handle, ol_req *req);
// Request handle to be closed. close_cb will be made
@@ -93,7 +94,7 @@ int ol_close(ol_handle* handle);
// Must be called for all handles after close_cb. Handles that arrive
// via the accept_cb must use ol_free().
-int ol_free(ol_handle* handle);
+void ol_free(ol_handle* handle);
View
@@ -1,6 +1,7 @@
#include "../ol.h"
#include <stdio.h>
#include <stdlib.h>
+#include <assert.h>
#define BUFSIZE 1024

0 comments on commit b17dcd5

Please sign in to comment.