[zeromq-dev] IOCP

Kelly Brock Kerby at inocode.com
Sun Aug 29 00:03:03 CEST 2010

Hi folks,

> Basically, send/recv operations on a socket are encapsulated in
> src/tcp_socket.cpp. You many notice that it's already ifdef'd for Win
> platform, so any changes needed can be done there without affecting
> other platforms.
> As for polling, you have to create a new poller class (iocp_t). The API
> should mimic existing polling classes (select, poll, epoll, etc.):
> For plugging the new poller class in, have a look at poller.hpp. What it
> requires is a single typedef:
>          typedef iocp_t poller_t;

	I've plugged in an iocp_t poller and replaced select in the
http://github.com/All8Up/zeromq2 fork, it is non-functional but does bring
up the iocp and such without crashing.  I have to add the AcceptEx/ConnectEx
functionality to get things working, but I'm out of time today.

	This is a VERY evil initial get something up and working attempt so
please do not go looking at it for cleanliness/error checking etc at this
time. :)

	Note: when I made the fork, there was an error in socket_base.cpp at
approx line 162, it was checking for "ipc" protocol but the comparison was
"!=" instead of "==", so bind always failed on Win32 if you "didn't" use an
ipc protocol.  "local_lat" was failing with valid parameters on Win32.

> > 	I've read that article before, very good.  But, as you say, IOCP
> > code tends to be very difficult, especially when you start worrying
> about
> > all the little optimizations and details.  My thought right now is to
> +1
> Simple implementation would get the basic infrastructure right. Trying
> to optimise straight away is likely to make the design chaotic.

	Currently I'm trying for as close as possible to the epoll version.
This is not a great way for iocp to work but I figure with something up and
functional we can work out how to push out better support later, though even
the bad way is likely better than using a select loop.

	If you grab the code keep in mind the following:

1.	The send code won't work as written, a zero byte send is a nop, just
did that for a placeholder.  My intention is to change it to a
"PostQueuedCompletionStatus" to initialize the send in the worker thread.
Unfortunately that will require some way to associate the send in the
socket_base with an OVERLAPPED structure which currently I have in the
poller code right now.

2.	Both accept and connect will need to be completely different in the
base sockets.  And you have to query for the functions via GUID, total
lameness but standard Win32 crap.

3.	I've posted the code only because others are interested and I'm not
going to get back to it till sometime tomorrow.  Please take it as intended,
just a quick see what we can get up and working without any major changes
first, then work out the best way to push out changes which are compatible
with everything and allow IOCP to actually be fast.

	Also note: I posted up a quick premake4.lua if you want to use it.
I'm just using it for a little testbed and it's not 100% correct.  I know
*nix folks prefer autoconf and all that, I just like being able to build IDE
projects for debugging purposes mostly because I'm spoiled anymore.. :)

> Go to http://github.com/zeromq/zeromq2 and click of 'fork' button.
> You'll have to use git then which may be pain in the ass at first if you
> are not familiar with it, but it _really_ is a better collaboration tool
> than SVN.

	I'm perfectly willing to use git or anything else, not picky as long
as it works.  Made the branch above and muddled through commiting the
relevant iocp starting point tests.  Hopefully I didn't screw anything up..


More information about the zeromq-dev mailing list