|
From: | Fabrice TOMASI |
Subject: | Re: [Xenomai-main] Exiting the Xenomai emulation |
Date: | Wed, 26 Nov 2003 15:31:04 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 |
Mmmm... with a longjmp in a signal handler ? Just kidding. If I remember correctly, pressing Ctrl-C works, so the loop is not as infinite as it seems. Ok, I'll check that this week-end and try something better (the original intent was to pthread_cond_wait for the threads counter to reach 0, but I do not remember why, it did not work).
Ok, thanks....
> By the way, I've got another problem with this new version. When > calling xnpod_start_thread(), it first locks a mutex > (xnmutex_lock(&kmutex)), then it calls the xnarch_init_thread() > function. In this function, the new thread is created by > pthread_create(), but for a reason I can't explain myself, this pthread > library call never returns when the scheduling is set to SCHED_FIFO (it > works fine with SCHED_OTHER). As a consequence, the mutex is never > unlocked hence the posix_thread_trampoline() and the posix_tick_timer() > are blocked too and the simulation is freezed !! Do you know why this > behaviour occurs ?Sorry but I can't send you any piece of the source code.....But, several tests have been done in order to fix this problem, there are the results: - a thread is created using the xnpod_init_thread() function, followed by the xnpod_start_thread() and xnpod_suspend_thread(XNSUSP, XN_INFINITE) functions. So, this thread is suspended. - later, this thread is resumed with the xnpod_restart_thread() function and it starts to create other threads. When this thread is resumed with xnpod_restart_thread(), the pthread_create() doesn't return, but when it is resumed with xnpod_resume_thread(XNSUSP), everything is ok. - then, I used LTT to understand why pthread_create() doesn't return. The mecanism of a pthread_create() is: clone() + kill the father with signal 32 + poll() + wait for a timeout. When pthread_create() doesn't return, it is due to the timeout which not expires or maybe it expires but the process doesn't remain in a ready state. - So, I thought the problem were within xnpod_restart_thread(). In fact, I looked at the old posix.h and found a difference in the posix_thread_trampoline() function. The two lines:Well... I never saw this, you undoubtly found a bug, could you provide me with a minimal excerpt of code which produces this behaviour ?
setjmp(tcb->rstenv); tcb->restartable = 1;are placed just before "tcb->entry(tcb->cookie);" in the older version but not in the version from the cvs. So, I moved these lines just before "tcb->entry(tcb->cookie);" in the cvs version. Now, it works better. Most of the tests for our emulator works now but some of them still doesn't (for the same reason).
I hope this will help you to understand what's happening..... Fabrice
[Prev in Thread] | Current Thread | [Next in Thread] |