Peter Graf writes: >>>An issue regarding re-scheduling of jobs under QDOS/SMS: >>> >>>As far as I remember, the job scheduler is triggered only if: >>>(A) It is called directly from the frame interrupt about every 20 milisec. >>>or >>>(B) After certain non-atomic traps that can be called from user mode. >>> >>>Now imagine we have a high-priority job which is blocked waiting for input, >>>a low-priority job which the scheduler has switched into execution just a >>>milisec. ago, >>>and we have just received input data by an external interrupt routine. >>> >>>Has the external interrupt routine a chance to cause a re-scheduling of >>jobs, >>>before one of the events (A) or (B) takes place? >> >>in jsrom, the answer is no. Fixing the OS should be trivial. >> >>>If not, it would mean that the high-priority job needs to wait up to 20 >>>milisec. before it can actually use the asynchronously received data. Not >>>very nice for networking applications, where an average response time >>of 10 >>>milisec. is quite a lot these days. >> >>true. >> >>Richard > >Thanks, Richard. Precise and clear as usual :-) > >For me this means that I will wait for a fix of the OS >before I care about writing a clean driver with ISR for >ethernet. After the OS has been fixed: Wether the ISR will >actually fill any RAM buffers or just wakes up a usermode >job that reads from the hardware buffers on the network card >and translates them directly into the TCP/IP stack's >internal buffering scheme, remains to be seen. I tend to >avoid double data copying.
I brought this matter up with Marcel. Here is his suggestion: # He can request a re-schedule simply by setting the sys_rshd system # variable to $FF. This will then be checked every time an SMSQ trap is # invoked, which should normally happen very often. I think this should # be good enough for his problem. # # Marcel This, of course, does not guarantee a reschedule within any given time frame, but it may be enough? Per
