State of IOCP work

[Marc Lehmann]

On Thu, Dec 09, 2010 at 12:37:48PM +0100, Bert Belder <H.Belder at student.TUDelft.NL> wrote:
> 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 :).

> 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 existance of a working patch (or better: separate backend)?
> 
> A separate backend would be my preference as well.

should be easy to add, the glue code is all there already.

> > The requirement would simply be that it works with the same types of
> > handles as before (minus the internal signal pipe), and implements the
> POSIX
> > event model to the application.
> 
> What do you mean by 'the POSIX event model'?

POSIX (basically the same as the single unix specification nowadays) is
the world-wide de-facto standard for oeprtaing systems that almost all
operating systems follow (even microsoft had plans to do that 17 years or
so ago).

POSIX specifies multiple ways to get readyness notifications from
the operating system, and the semantics of these is what libev
offers to the application (almost, libev makes the additional
requirement that files cannot be used for I/O events, as
stupid-ever-broken-design-by-idiot-asshole-dumbheads epoll fails with
files).

Since this is both what real-world programs expect and is also the model
commonly used and known by programmers, this is what libev would need to
implement on windows.

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, 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.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\