On Sat, 2010-08-21 at 19:36 +0200, Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
> > There are other issues to consider, such as detecting that a private
> > mutex created in the father continues to be used in the child.
> A simple fix for this would be to keep a list of mutexes in the native
> and posix skin, and nullify their magic/opaque pointer at fork. The
> problem is that there is no more room in pthread_mutex_t, so we will
> have to malloc at pthread_mutex_init time.
Please simply issue a warning as you suggested once when a potentially
dangerous situation arises upon fork regarding mutexes. Piling up
non-trivial code to prevent an obviously broken application from
misbehaving even more is way too expensive if such code could introduce
more overhead, and potentially secondary mode switches.
IIUC, we are discussing about apps using in a child context some private
mutexes which were initially created in the parent context, right? If
so, then a warning upon detection should suffice to have the author go
back to the drawing board, and optionally run "man pthread_mutex_init"
Xenomai-core mailing list