On Wed, Jun 04, 2008 at 11:37:50AM -0400, Thomas Harning <[EMAIL PROTECTED]>
wrote:
> >and that might well be true... to get perfromance out of windows, use
> >threads. preferably thread pools.
> >
> I think they mean that you want to use separate threads for
> computation and data communication....
Exactly: use threads (and blocking operations) and not non-blocking
operations.
> I think I recall finding that IOCP either uses a thread-pool or
> interrupts currently executing code for its callbacks... so you'd have
> IOCP perform data management and on completion do the minimum amt of
> work (queue up the data to be processed).
Note that IOCP are the wrong approach to sockets - they work fine for
files, but not for sockets. Window smight force you to use them for
sockets to get performance, but thats another issue.
> This doesn't quite fit into libev's workflow directly (booo!), though
> one 'could' create some interesting layers...
It's not libev's workflow, it's the workflow of about every other OS out
there. It's standardised by POSIX as well.
One should be careful before punishing the majority of well-designed
platforms just because of the atrocity of one platform with a business
agenda of being incompatible.
> Ex: something like libeio's interface could take advantage of some
> items transparently, or a layer for libev that handles data transport
> and alerts you to readiness for data available in filled buffers or
> buffers have room to put data (kinda like the bufferevent
> abstraction...).
Not quite - libevent's buffer thingy is the right thing here - it could do
the right thing on unix and abuse iocps on windows because its the only thing
that works well there.
I cannot imagine that this interface would be even remotely similar to
libeio's api, though, the problem is just too different.
I also think it is pointless to implement such an abstraction just because
of a single abysmally broken platform (glib does that for example, and the
result is quite portable, and quite horrible).
If one restricts oneself to sockets, however, the other approaches
possible with winsockets should be explored as well - sockets *do* support
the posix model, just the mapping is non-trivial (yeah, you need threads,
and a window handle) (but the mapping from the broken windows select to
posix semantics is quite horrible as well, so it doesn't mean it isn't
doable).
For libev, using async notification for sockets is definitely more useful
and has more future then forcing everybody to use some api only required
for windows performance.
If somebody made himself the work to implement a specific winsockets backend
that used async notification and needs extra configuration in the form of a
window handle, that would be nice.
And it would mean that applications can take advantage of it without
sacrificing speed and good design just because of windows.
windows *is* a second class citizen, and performance on it is quite
unimportant, as long as you can write programs that work efficiently
elsewhere and still work correctly on windows.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
