State of IOCP work

[Bert Belder]

[To Marc: oops. I keep replying to the wrong address. Sorry]

> > I don't quite understand that, unless you're meaning that FD_WRITE
is
> > 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()
> call
> > to determine if those sockets are still writable just before
invoking
> > the next wait?
> 
> Yeah, but since we are callign select anyway, what again is the
> advantage
> 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
disarmed.
 
> 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.

- Bert