Now, as Philippe says:
Apparently all pthreads are handled through processes on ARM,
I've seen the same with apache2-mpm-worker where what should be
plenty of threads becoming standalone processes.
Probably a kind of thread emulation if the ARM arch doesn't allow
native support of threads, no idea...
I don't have much experience with threads, but I am wondering: would
it be interesting to create a specific version of tuxdaemon for
embedded systems, based on forks and no longer on threads ? It might
be handled more reliably, be easier to compile using the different
SDKs and should not require lots of modifications.
Any advice ?
I guess we need the following structure in any case:
USB <-> status structure and command stack <-> TCP/IP
I don't have any experience with threads and TCP/IP but can't we do
without threads at all? Isn't select() supposed to call a function when
data is available?
Now we could also use pipes to communicate with a separate USB process as
the data can be kept as raw there.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tux-droid-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tux-droid-user
