At 03:12 PM 6/19/01 -0600, Richard Gooch wrote: >New FAQ entry: http://www.tux.org/lkml/#s7-21 > >Yeah, it's probably a bit harsh :-) It's also incomplete, in my view, to the point of being misleading. Part of the reason I'm reacting so harshly to this FAQ entry is that it flies in the face of my own experience. I do a lot of real-time and near-real-time programming, and find that the process and thread models are essential to the proper and expected operation of my code. The FAQ answer neglects this entire area of applications. For details: I run a process (not threads as yet, but it will happen) for each event I need to react to in near real time. The running priority of these processes are set as high as possible so that when the event occurs the newly-unblocked process is guaranteed to run almost immediately. These processes, when unblocked, do the absolute minimum amount of work to meet the real-time requirements and then block again. If an event requires extended processing to begin but not to complete in real time, the event process sends an appropriate signal to the main process to perform that extended processing. The main problem with the comment in the FAQ entry that "it's easy to write an event callback system" is that the response time may not meet the needs of the application, particularly in computer systems that have multiple near-real-time applications running at the same time. The key design point in this near-real-time model I have described is that it does not violate the rule of thumb described in the FAQ answer, that the Linux kernel is designed to work well with a small number of RUNNING processes/threads. Ideally, a high-priority process should run for much, much less time than the standard time-slice so as to minimize the number of scheduler elements marked as "ready to run." My standard is for a high-priority process driven by an event to run for no more than a millisecond or so, and leave any heavy lifting to the main process to take care of when the main process gets around to it. For true real-time processing, you have to write device drivers to react to external events directly, a programming task that is more burdensome and error-prone. Or, better, use a real RTOS instead of Linux. When the real-time requirement isn't so critical, though, the method I have described allows the whole thing to be done in userland, where it can be debugged far more easily. In summary, writing code to use many processes or threads is NOT lazy programming in all instances, as the FAQ answer implies. Stephen Satchell writing time-critical programs for only a short time -- 30 years. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
