Michaelwagner said the following on 12/10/2005 14:22:
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.
Exactly. But that relies on everyone writing code for slimserver to
yield regularly if their code take any length of time to execute.
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.
Language is irrelevant. multi-process/multi-thread systems can be
written in pretty much any language. qpsmtpd is an example of a program
written in perl that can multi-task and handle high loads.
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.
I don't think a re-write in C would help - that's analogous to throwing
hardware horsepower at the problem.
If the core code is broken out into separate threads/processes with
clearly defined interfaces then each process can be written in whatever
language you like. I think each core element of the code should have its
own process/thread rather than just one as you suggest. 6 processes
would be not much harder to implement than 2.
R.
--
http://robinbowes.com
If a man speaks in a forest,
and his wife's not there,
is he still wrong?
_______________________________________________
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
