>> >> I know that using separate fibrils may be beneficial for some drivers, >> but I still think the handling of notifications is currently broken. The >> problem is not in the size of the stack (although allocating whole page >> when you just need to process a few bytes seems like a waste of >> resources if you ask me), but the real problem is that there is *no >> upper bound* on the number of fibrils spawned. In most cases you just >> need a few fibrils anyway, because you have a limited number of things >> you do in a driver (e.g. for audio you might have as many fibrils as >> there are channels you are handling, but this number is low and doesn't >> change much over time). > > I don't see a reason why there should be an upper bound on the number > of fibrils used. The only problem I see is that failure to create new fibril > is > not handled gracefully. In general I don't see high number of fibrils > as a problem, >
The fact a simple driver exhausts all available memory any time the system is not fast enough to process all data the hardware throws at it, seems like a pretty serious defect. You can't just say that the systems needs to meet hard real-time constraints, regardless how lenient they might be, in order not to collapse. That is just not the sane way of designing general purpose system. -- Jirka Z. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
