Robin Bowes Wrote: > However, the current architecture is such that any blocking operation > will interrupt audio streaming if it blocks for long enough. >From looking at the code, it seems that perl has no built-in interrupt handling or dispatching, and that all dispatching is being handled by hand-written code. So the operation doesn't have to block, it just has to call some subroutine that takes a while (like an sql call), and that's all she wrote.
> It's more about spreading the processing power between the necessary > processes. The core "real-time" processes need to run uninterrupted, > e.g. audio streaming, display update, response to remote, etc. Other > stuff, like playlist management, scanning, etc. need as much CPU as > possible but without interrupting the core processes. This would be > easier to achieve with a multi-process/thread architecture. Multi-process/multi-thread is fairly complex and this isn't the right language. But 2 process/thread is more achievable, given the tools and the language, and I believe adequate to the task at hand. It won't solve the problem that 14 people in a library pounding away at the web interface will get lousy response, but that's not really the intended use. A separate perl low-level routine that just kept the active clients fed with music and display information and serviced remote control keyclicks (all the time-critical stuff) would actually simplify all the rest of the code, which then wouldn't have to mess with timers and "make sure I don't do too much" code. And it could serve as the model for a rewrite in C down the road. -- Michaelwagner _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
