Hi Michael,
Michael Schnell wrote:
I said uClinux, so specifically I mean non-MMU varieties of Linux.
Of course I do know the difference. I'm going to do an embedded
controller project. So I'm very likely to use µcLinux
As of 2.6 we have a Posix threads representation in the Kernel
(NPTL). This should have changed the behavior of threads.
What architecture?
Supposedly NIOS. I do know that Altera is going to release an MMU for
that processor very soon, but that will reduce the performance by up at
least 10 % and while the 2.6.23 µCLinux for NIOS is just getting ready,
I suppose that there will be a while until a decent "full" Linux
distribution is available.
Its the testing/support aspect that is more problematic for threads
on some architectures. Search back through the uClinux archives,
m68k(nommu) for one occasionally has broken thread support. Certainly
if I am debugging an odd problem on m68knommu using threads, I would
look closely at that first.
I am sure some people will stand up and say threads work great
for them on specific architectures.
If you are heavily using threads then you are essentially
working around the protections provided by your MMU anyway :-)
Anyway: While I do see that and why why fork() is not available in
µCLinux and thus spawning a process is not as easily as it is in full
Linux, I can't see what problems are introduced regarding threads.
Spawning processes is simple. vfork works great. It just has slightly
different semantics to the traditional fork(). Go crazy, spawn as
many processes as you want, it is not a problem on uClinux (of course
memory resource is likely to be your limiting factor).
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
