Philippe Gerum wrote:
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
as well.
Ok. Detection is not that easy with fastsyncs, so here what I set up to do:
- for mutexes going through the syscall path, return EPERM (the
documented error for that case), and print a message inn the console.
- for mutexes going through fastsync, cause a segmentation fault to kill
the application by setting up an inaccessible mapping where the private
heap was, this is better than potential silent memory corruption (the
current situation). But needs be documented.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
