Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)
Status: Beta
Brought to you by:
ks156
From: Philippe T. <ph...@te...> - 2007-04-23 22:11:25
|
Hi all, Some more progress with the last trunk on ARM. What I changed to get sth working up to now: Commented out pthread_cond_wait() in the tcp_server otherwise it never starts. 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 ran the tuxdaemon on the slug and took control with gtdi from my laptop. 1st problem: I can do some actions but after a while the gui "slows down", feedback takes always 1 second when I do sth and the actions aren't performed anymore. If I restart the daemon the gui recovers very nicely till the next freeze, probably always on the daemon side. 2nd problem: After one of those freezes when I ctrl-c the daemon, I got a segfault, unfortunately I didn't get any code file, ulimit coresize was =0 and since I enabled it I could not reproduce the crash. So just a little tip for all devels here: be sure to set ulimit -c to some high value to be able to capture any segfault when it happens ;-) 3rd problem: Still as before, it looks like all forked processes (those which should be threads) still go through the main code at exit time and I get: Daemon closed Daemon closed Could not delete PID file Daemon closed Could not delete PID file -> one of the three already deleted the PID file and the 2 other complain that they cannot do it themselves. Looks like all processes herited the signal(SIGINT, on_close_daemon); and that an exit() has no effect on the other processes, which seems logical but different from what threads do. So I don't know how to maintain the thread architecture in a way compatible with ARM. 4th problem: As I said I could not use yet pthread_cond_wait() 5th problem: As I said in a previous mail only one of the processes actually changed its UID to nobody while on i686 the three threads are actually changed to UID nobody Phil |