James A. Donald wrote: > A python program on QT is usually written around a message pump, so > logically disk io completion events ought to arrive in the message > queue, like mouse events and keyboard events, but it is not apparent to > me that this is the way QT asynch file IO was designed.
Yeah. One of the more modern select() replacements (on solaris or something) went with the most sensible approach, which is that *everything* is an event: network, fileio requests, signals, child process events. Unfortunately it's so far out that nobody seems to use it :). I suppose it might be worth experimenting with doing IO in one thread and passing events through reactor.callFromThread(), except I suspect the GIL would render that useless. It might also be worth doing IO in one process and communicating (maybe over shared memory) with the main reactor process, but the overhead could be significant. I think it's another example of asynchronous interfaces being such a different approach that they really want all the code around them to be async too. It's awfully hard to mix sync and async code in the same program, and most programs are synchronous, so the async fileio code has a tough time getting acceptance, so it never really gets improved/fixed/etc. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
