xenomai-main
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xenomai-main] Exiting the Xenomai emulation


From: Fabrice TOMASI
Subject: Re: [Xenomai-main] Exiting the Xenomai emulation
Date: Tue, 18 Nov 2003 11:40:02 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624


Exit() does not work with the 1.1.1 posix.h, because the manual
scheduling is done with SIGSTOP/SIGCONT. If you use posix.h from the
CVS, the manual scheduling is done with POSIX condition variables, so
that exit() should work correctly. The adaptation of the newer posix.h
to the RTC driver should be as easy as for the older.

Ok, I've upgraded the posix.h from the CVS as you said and simply replaced the posix_tick_timer() by the RTC driver.

The only way I know to "cleanly" exit an application with pthreads, is
to cancel all the running threads but the main thread, decrementing a
counter in the "top" cleanup handler and signaling a condition variable
when this counter reaches 0, which wakes up the main thread. Unfortunately you then have to be prepared, in each thread, to be
canceled at any (cancelation) point. I would recommend to use this
"clean" exit only for leaks research with valgrind/kcachegrind. The rest
of the time, relying on the OS is simpler and faster.
Yes, the leaks research is the only reason for us to use a clean exit (the research is done with ccmalloc)....So, we can't call the exit() function. In the new posix.h, the clean exit can't be called because in the main() function, there is an infinite loop:
   for(;;)
       pause();
posix_cleanup_application();
   posix_cleanup_interface();
   posix_cleanup_nanokernel();

   exit(EXIT_SUCCESS);

So, how can the posix_cleanup_*() be called ??


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 ?


            Fabrice





reply via email to

[Prev in Thread] Current Thread [Next in Thread]