State of IOCP work
H.Belder at student.TUDelft.NL
Thu Dec 9 13:25:12 CET 2010
[To Marc: oops. I keep replying to the wrong address. Sorry]
> > I don't quite understand that, unless you're meaning that FD_WRITE
> > edge-triggered.
> Exactly (but that's not the only problem you also have to generate
> events for connects and accepts - although this could probably be
> handled by doing handle type detection in some way, and some quite
> horrible code - at least, thatw as my impression :).
Why would FD_CONNECT and FD_ACCEPT not work?
> > In that case, wouldn't it be possible to mark sockets that have
> > writability signaled 'writable' and using a zero-timeout select()
> > to determine if those sockets are still writable just before
> > the next wait?
> Yeah, but since we are callign select anyway, what again is the
> of select+extra high overhead stuff vs. just select?
The advantage would be that wait() can wait for other stuff. I don't
really mean to check 'writability' and 'readability' of other handles,
but just wait for some handle to become signaled.
For example I need to wait for a child process to terminate. ev_child
won't work because it relies on SIGCHLD which doesn't exists on windows.
That doesn't mean its difficult to wait for a child process: windows
will signal the child process handle as soon as the child process exits.
But select can't wait on that handle. Same story for console input: you
can wait for a console handle, but not with select. So my idea was to
add a windows-only ev_winhandle watcher type to handle that kind of
stuff, but then I need a libev backend that does wait for handles while
not regressing over the existing select backend otherwise.
Wrt the performance impact. Select is particularly slow when you try to
select on a lot of handles. That wouldn't be needed in this case,
because now we'd need to select only on sockets for which FD_WRITE is
> In theory, it would be possible to make a non-default backend that
> has additional requirements (as kqueue basically is on many operating
> systems), such as signalling write result codes or somesuch,
It could be an alternative to the select trick, if that's what you mean.
It is known that, as long as a socket op doesn't fail with
WSAEWOULDBLOCK it is writable. And if it does FD_WRITE is rearmed.
> but since performance on windows is rather bad even with
> "perfect" use of iocps and other advanced features, it's hardly
> worth the effort - windows support is good to have, but obviously,
> nobody is interested in performance when using windows.
Sure. Performance isn't my primary concern here, although I wouldn't
accept a big performance regression over the select backend proper.
More information about the libev