
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
On 28 Nov 2003 09:05:07 GMT, [EMAIL PROTECTED] (Nick Maclaren) wrote: >I/O is trivial; interrupts always were a bad way of doing it, and many >older systems did it other ways. Consider, for example, I/O requests >that don't block and I/O responses that are put into a queue for >handling when the driver next gets around to it. FIFOs are not exactly >unusual in hardware :-) > >Alternatively, you can go for a seriously multi-threaded approach and >have all I/O operations blocking, so you need to spin off a new thread >for each one. Not a major issue if you have enough threads available, >but it needs a lot of hardware threads - which is perfectly possible >on modern chips. True, those would work. >Multitasking was done without interrupts on quite a few of the earlier >machines - what you mean is preemptive multitasking (i.e. not the >coroutine approach). Each process yields control when it gets to >suitable points, which are required to be no further apart than a >certain time. Apple took that approach for a long time, and its >only problem is that a failing program can block the hardware thread. Yeah... that's a showstopper unfortunately, at least on a general-purpose machine that's going to have to run a random collection of programs, many of them badly written. >My solution to that was an architectural requirement for a 'yield' >instruction to be called every (say) M instructions or N memory >references, whichever comes first, and to abort the process if it >failed to do so. Dead easy to implement. Hey, that's a good point. Just have a counter count down on each instruction executed... that would work. >So where's the problem? :-) Okay, problem solved ^.^ -- "Sore wa himitsu desu." To reply by email, remove the small snack from address. http://www.esatclear.ie/~rwallace
| <-- __Chronological__ --> | <-- __Thread__ --> |