Re: [Xenomai-main] Exiting the Xenomai emulation

[gilles . chanteperdrix]

Fabrice TOMASI wrote:
 > >(...) 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 ??

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).

 >     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 ?

Well... I never saw this, you undoubtly found a bug, could you provide
me with a minimal excerpt of code which produces this behaviour ?

-- 


                                            Gilles Chanteperdrix.