Linked by Eugenia Loli on Sat 30th Sep 2006 20:04 UTC
Thread beginning with comment 167149
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
The windows kernel architecture is fully asynchronous. The problem that is being solved here is the one which happens when a thread performs synchronous IO which then hangs until the timeout (often on the order of 30 seconds to allow for really slow network connections). Sometimes the driver doesn't even complete the operation ever. The CancelIO facility allows another thread to stop another thread's synchronous activities.





Member since:
2005-07-24
Having now watched the video.. I do have a more simple answer to their I/O problem..
ASYNC BELOW APP LEVEL, Report into journal the I/O you would otherwise wait for synchronously, would now be waited for... with a reasonable timeout, allow X number of failures before (based on error type) reporting back to the app with an error.
Ideally, you wouldn't have to go below app level, but backwards compatibility would demand it.
Though, the problem would be far less of a problem if Windows developers could just utilize threads more effectively, though I think that has more to do with Windows API and coding habits more than anything.
I can just create a thread by typeing spawn_thread(),
passing a function and a variable to pass to that function, naming the thread, and giving it a priority. I can then cause that thread to run with resume_thread(thread_id). So, naturally, these problems simply don't make much sense to me... not to mention my running a real-time capable kernel. Threads cost NIL here, and lots on existing programs and platforms which do not utilize them.
That and many developers simply can't properly abstract (mentally) the workings of multiple threads.
Oh well, if the solution that MS implemented works for Windows, or not, will only be known in time.
--The loon