Is it safe to make all your interrupt handlers functions which put the interrupt number in a queue and assign it a priority?
Things like the timer and exceptions would bypass the queue, because those need to be handled.
Floppy interrupts would go in the queue.
INT queue?
-
Peter_Vigren
Re:INT queue?
Well... It should be... I think... But I'm not completely sure... Hm...
The keyboard interrupt for an example... if it isn't serviced right away... you might loose some keypresses... And the floppy interrupt... if it is not handled... the code who used the floppy won't know the floppy has completed... and then some other code can't use the floppy until serviced...
The keyboard interrupt for an example... if it isn't serviced right away... you might loose some keypresses... And the floppy interrupt... if it is not handled... the code who used the floppy won't know the floppy has completed... and then some other code can't use the floppy until serviced...
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:INT queue?
You can split the Interrupt handling:
one small part which fetches the Data that a device has produced and stuffs it in some sort of buffer and then fires an event (a message) for a task that is responsibe for handling the data from that device (p. ex. keyboard data translating, passing characters entered by user to console/user process (via message)). In linux this is solved by so called tasklets: The actual interrupt service routine fetches data and stuffs it in some buffer, then it marks its tasklet (a kind of thread which sleeps i think) to be executed before entering the next task. The tasklets to be executed are stuffed in a queue and called each after an other upon executing the scheduler. You can also solve this by firing a software interrupt which handles all these tasklets.
The important thing is: The isr has to take immediately care of the device it is responsible for: fetching data, resetting states usw. because internal device buffers can change quickly so there is no need to hesitate - because isr is stuffed in some lenghty queue.
stay safe
one small part which fetches the Data that a device has produced and stuffs it in some sort of buffer and then fires an event (a message) for a task that is responsibe for handling the data from that device (p. ex. keyboard data translating, passing characters entered by user to console/user process (via message)). In linux this is solved by so called tasklets: The actual interrupt service routine fetches data and stuffs it in some buffer, then it marks its tasklet (a kind of thread which sleeps i think) to be executed before entering the next task. The tasklets to be executed are stuffed in a queue and called each after an other upon executing the scheduler. You can also solve this by firing a software interrupt which handles all these tasklets.
The important thing is: The isr has to take immediately care of the device it is responsible for: fetching data, resetting states usw. because internal device buffers can change quickly so there is no need to hesitate - because isr is stuffed in some lenghty queue.
stay safe
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:INT queue?
Interrupts are designed to be serviced by the CPU as soon as possible. Now, it may happen that some interrupt actually has to queue some data (for instance, the ASCII character that was pressed, waiting for the APP to give it a response (should it be displayed or not ?).
For instance, your HDD interrupt should at least get back the data from the controller before it queues the fact that these data are now ready, so imho, just queueing "we got INT XX" is not that interresting ...
Or maybe you have reasons wanting to do this, but i don't see which ones...
For instance, your HDD interrupt should at least get back the data from the controller before it queues the fact that these data are now ready, so imho, just queueing "we got INT XX" is not that interresting ...
Or maybe you have reasons wanting to do this, but i don't see which ones...