On 04/20/2013 04:21 PM, Ján Veselý wrote: >>> Interrupts that arrived later can be handled sooner/faster. >> Well, just spawning a new fibril does not help by itself. You either >> need to have multiple kernel threads or wait for some condition (so >> there is a fibril switch) to actually handle the interrupts in different >> order. But once you start waiting for some condition in an interrupt >> handler (e.g. a buffer you are writing to becomes full), it is very >> likely that the other fibrils handling the same interrupt type will >> become blocked as well. > > yes, the point is that by having multiple fibrils only those that use the same > resource get blocked, others can continue their work. adding more > threads to fibril manager is easy and we should not base design decisions > on the fact we currently use only one. moreover there are other opportunities > than locks for fibril switch. If there were none but locks, we could > remove the locks and rely on cooperative fibril scheduling to avoid > race conditions. The problem is that as soon as there are enough blocked fibrils, it is not possible to spawn new ones, so just one resource can stall processing for *all* the other resource types (in other words you discard all new notifications because you are not able to allocate more fibrils). So e.g. a bug in the mouse driver could render the keyboard inoperable and vice-versa. If the driver was responsible for handling the notifications, it could easily drop only the ones belonging to the mouse and continue processing the keyboard ones.
Martin Sucha _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
