Michaelwagner said the following on 12/10/2005 15:17:
Robin Bowes Wrote:
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.
In theory I agree with you.
In practice, I was looking at what is practical and achieveable in a
short time and with limited staff resources. I wasn't advocating
writing our own generalized scheduler/dispatcher. I was advocating
running 2 copies of perl, one with the time-critical stuff, one with
the rest. And prioritize the time-critical one higher. Let the
operating system dispatch the two of them.
I'm not necessarily advocating writing our own scheduling code - that's
what the operating system is for!
You don't want to have 6 because you don't want 6 operating system
processes running.
Why not? If there is a need for 6 processes then why not have 6
operating system processes?
Some of the best software I use is written by djb (http://cr.yp.to).
Daemontools, ucspi-tcp, qmail, etc. Lots of small programs that do a
specific task well. YOu get the functionality by chaining the processes
together, e.g. to start the qmail smtp listener you use something like:
exec /usr/local/bin/softlimit -m 3000000 \
/usr/local/bin/tcpserver -v -R -l "$LOCAL" \
-x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 \
smtp /var/qmail/bin/qmail-smtpd 2>&1
That's softlimit running tcpserver (which handles the tcp
communications) running qmail-smtpd.
Logging is done by piping the output of this process to yet another process.
If slimserver were written in a similar way it would make development
and maintenance much easier.
R.
--
http://robinbowes.com
If a man speaks in a forest,
and his wife's not there,
is he still wrong?
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
