Phoebus Dokos writes: > <snio> > >I see only two possible solutions for QDOS/SMS: > > > >(1) A higher rate for the frame intterrupt (disadvantage: higher system load) > > > > This would be feasible I think without too much problems for the system.
Not really a good idea, I think. As Peter demonstrates with his example, there isnt really an issue with the scheduler frequency. In most cases a job is serviced more often than 50 times a second, in fact 20 milliseconds is the max time between scheduler calls. > <snip> > > I always believed that the way I/O is implemented might have been good for > extremely slow peripheral devices and with media that wasn't exactly reliable (ie > making sure that SuperBasic for example did actually save the changes before you > could return control to it) but for today's requirements it is totally obsolete. But microdrive access, slow and unreliable as it is, did not hog the whole machine, iirc. Why then floppies and hard drives? > On the other hand and IIRC IOSS in itself is a different scheduler that could be > tuned without resorting to drasting measures (ie overhauling the whole system). > Please note that drivers (according to everything I have read) do not > *NECESSARILY* have to get into Supervisor mode to go about their business(sic!), > it's just "strongly advised" (I quote from Adrian Dickens) that they should do so. > > >Do you see what I mean? A simple job can cause *immediate* job > >re-scheduling. A properly implemented device driver can not (as it seems). > > See above... A properly implemented device driver can be in fact be a simple job (or > have I got it all wrong) if the writer chose to, it's just a lot simpler if you don't > implement it that way because after that you have to cater for all sorts of > possibilities. I think you will find that real hardware drivers need to work under external interrupt or under the polling interrupt loop, ie they work in "supervisor" mode. > The "correct" implementation according to my VERY HUMBLE opinion would be to > implement the IOSS as a set of two jobs. One vectrored routine (along the lines of > what we have now (which would also ensure compatibility)) which would then start > the actual scheduler AND driver. According to the type of driver that would be > invoked that would close later if it wasn't needed or -in the case of a say ethernet > packet driver- keep on working... something like the DETACH command in OS/2 > (remember that one?). You set it and forget it in other words... The separate IO > scheduler then (for drivers/jobs that were still in use) could be tuned to our desired > response..... (Or something like that in general). In theory we could have two or > three or more IOSS's running at the same time, all invoked from the same vectored > routine which would only serve as an entry point. (Not many, many more of course > as that would introduce other problems...) > > > Maybe I got it all wrong myself.... I don't know we're just brainstorming here :-) Per
