Am 11.04.2013 um 09:05 schrieb Gilles Chanteperdrix: > On 04/11/2013 09:00 AM, Michael Haberler wrote: > >> Gilles, >> >> I think I see the light although I'm not totally clear on all details yet: > > > There is a very simple solution, see my other mail: > http://www.xenomai.org/pipermail/xenomai/2013-April/028169.html
Well, 'simple' is just my kind of keyword, that one I'd manage I understand there are no dumb questions but rather inquisitive idiots, so let me rattle off my remaining topics in advance: - I read this to mean: forget about rt_heap* and rtai_(k)malloc altogether: if that is the case - any downsides in the crystal ball? - if it is that simple, why isnt everybody using this scheme over rt_heap_* and rtai_(k)malloc and friends which has the sequencing restriction? The overall approach looks a bit like this project: http://sourceforge.net/projects/mbuff/ and the author mentions an interesting point in the FAQ file: > WARNING > > All versions od mbuff have a known bug occuring when a program having mapped > areas forks. Do not do it for now. Attach to shared memory areas after > the fork in parent and child if neccesary. I do for now take that as a restriction which can be dealt with if it is known to exist even if I dont fully understand where it comes from; some old code remark in the RTAI userland code workaround in LinuxCNC hints that RTAI rtai_malloc()'d memory suffers, or suffered from a similar issue - Michael > > -- > Gilles. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
