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: Gilles Chanteperdrix
Subject: Re: [Xenomai-main] Exiting the Xenomai emulation
Date: Thu, 13 Nov 2003 11:08:33 +0100

Fabrice TOMASI wrote:
 > 
 > >It is unfortunately not very surprising that the application shutdown
 > >does not work very well, it was not very well tested. However, as far as
 > >I remember, the vxworks testsuite exited correctly and had a timeout. If
 > >you look at the code, I used xnpod_fatal().
 > >
 >     Ok.....We used xnpod_fatal() too for emergency exit in the emulation 
 > without releasing any resources. But, for the  normal case, we want a 
 > clean exit through the posix_cleanup_application() function and thus use 
 > the Xenomai exit mecanism.
 > 
 > > Another solution is to use
 > >exit() which will not work in kernel space, but I guess you do not care.
 > >
 >     Yes, as our emulation runs in user space, the exit() function can be 
 > called but the Xenomai exit path is broken....
 >
 > >By the way, what version of posix.h are you currently using ?
 > >
 >     It's a modified 1.1.1 (we had to modify it because of the use of a 
 > custom RTC driver) but it's not the one from the cvs.
 > 
 >     Thanks for your help
 > 
 >              Fabrice.


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.

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.

Regards.

-- 


                                            Gilles Chanteperdrix.




reply via email to

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