On Sat, Jan 18, 2003 at 10:39:58AM -0000, P Witte wrote: > Since only a > specific effect is required in rather exceptional circumstances, wouldnt it > be better to handle that from the calling code instead?
it isn't exceptional circumstances, I am really surprised why nobody noticed that before.. perhaps old QL devices were just so slow that another 1/50s didn't matter that much. Basically every interrupt except the 50 Hz timer will be on behalf of some job io so it seems quite natural to reschedule after interrupts. > Marcel has refined > his suggestion as follows. I quote: > > # By exiting the interrupt handler through the sms.rte function the > # requested re-schedule will be done immediately if possible (i.e. no > # supervisor code was running at that time). Example: > # > # include dev8_smsq_smsq_basekeys > # include dev8_keys_psf > # > # int_handler > # movem.l psf.reg,-(sp) > # > # [blah] > # > # st sys_rshd(a6) ; Request re-schedule > # move.l sms.rte,a5 ; ...now would be convenient > # jmp (a5) > > This, I believe, produces the same result, but without any chance of side > effects. if it works as advertised it would indeed solve the problem. It has an immediately obvious side effect - interrupt routines that are later in the chain will not be processed anymore. It would be cleaner if the interrupt routine would just set sys_rshd and QDOS/SMSQ would honour it after processing all other isr. > > sys_rshd is not a bad idea, it might be usefull if it had some > > at least this states: > > - no action > > - run through poll tasks > > - run complete scheduler > > > > That would probably require the complete rewrite of all the 10 lines > > of scheduler in jsrom :) > > Then why not go the whole hog and design a scheduler that will allow > time-critial "systems jobs" to run with "hard" priorities (while "user jobs" > get the remaining CPU cycles employing relative priorities, as before)? I don't have that good experience with hard priorities so I would think twice before complicating the scheduler for them. Otoh checking for sys_rschd after isr processing looks really trivial and top priority now. Richard
