From: "Gavin Lambert" <gav...@compacsort.com>
Quoth Jan Ringoš:
3) There is no practical distinction between process and thread in
uClinux
as there is in Windows world.
Untrue. Just as on Windows, processes have separate address spaces
(normally) while threads
have shared address spaces, and threads are owned by processes. The main
distinction between
Windows and Linux in this regard is that processes are significantly
cheaper to create in Linux
than under Windows, but processes are still heavier than threads.
Well, I am interested in uClinux only, in this case. I still don't see the
difference. If all the processes live in the same address space here, and
when I create a thread (pthread_create) I see a new duplicate process
through ps command (just as if created by vfork), then what can it be, that
would make pthread_mutex not work?
I am sorry, maybe I am little slow here. Feel free to stop me if I am
challenging some immutable truth :-) I do recall reading something about
changes from kernel 2.4 to 2.6. I am not sure what it was exactly, but I
should get my hands on 2.6 kernel version of the device soon.
5) There is no dynamicaly-loaded-library (DLL, or .so, or whatever)
support.
Depends on your architecture. Some arches haven't implemented it; others
have implemented a fairly
rudimentary version of shared libraries, still others have full support.
My architecture is Arm940T (S3C2500B board) running 2.4.22-uc0 kernel,
provided by Moxa.
I just found a line in their (IMHO far from complete) documentation that
says no, no shared libraries.
9) Or is my approach of multiple processes otherwise flawed? My intension
is
to minimize memory and disk footprint by including only components
necessary
for particular application. Have I other option than to write big
monolithic
process?
You could create a server process that accesses the database, and smaller
client processes that talk
to it (via sockets, files, pipes, or one of the standard shared memory
interfaces).
I think I can use the pipes (with their atomic writes) to get rid of any use
of mutexes in this case. But it will be otherwise a little more complicated
than just calling the exposed functions.
Anyway, thanks for helping me to move forward,
---
Jan Ringoš, j...@ringos.cz
www.ringos.cz, tringi.mx-3.cz
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
