Re: Terminate and Stay Resident Software (TSR) in Linux

Hi,

Your program would just wait for input. The process running your
program would then not be scheduled until some input comes.
Do you mean it is not running at all if no input comes through?
I thought every process gets at least a time slice every now and then.
Is this assumption thereby wrong?

Why give a timeslice to a process waiting for input that the scheduler
knows has not received that input? That's just a waste of resources.

Yes, that was my idea, too. I did not know how/if it's done.
I'll get the Minix book at Christmas, so I can then read some more about the
real low-level stuff. I have read a lot, but not about everything. A good
book is worth more than a thousand web sites, I think...

Every process is marked with a state which tells the scheduler whether or not to even try scheduling it in for a time slice. One of the states is "blocking" ie. waiting for something. When that something happens (usually in another process) the state of the blocked process is changed to "run". That way, when the scheduler next comes around to considering the process, it picks up where it left off.

-- Peter
.

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: Blocking read() policy?
    ... >> It doesn't require any particular advanced scheduler. ... Especially if pgms demanding short latency ... that a CPU intensive process would ... starts over with the shortest possible time slice. ...
    (comp.os.linux.development.system)
  • Which Kernel for soft realtime on ARM 9
    ... The most critical area for that effect was detected to be the Oscheduler that uses much more code than the 2.4 Oscheduler, while with only some 10-20 processes the Oscheduler is not faster than the Oversion. ... Moreover the higher time slice scheduling rate of 1 instead of 10 msec results in unnecessarily increased overhead. ... I did some tests with that and I found that the patch does not help much, when the IDE driver is used for a non-realtime process that runs concurrently with a high priority realtime process. ... The embedded ARM project will not do too much IDE driver work, so maybe the Kernel preemption patch might do a better job here, but a compact flash drive is planned be included and used sporadically. ...
    (comp.os.linux.embedded)
  • Re: [NT] Quantum of interrupted process
    ... operating systems. ... I believe a thread is not handed a time slice ... I believe any interruption time that a thread ... will the scheduler switch to P3 with Q3 ...
    (microsoft.public.development.device.drivers)