Gilles Chanteperdrix wrote: > Jan Kiszka wrote: > > Hi, > > > > this patch moves the heap for scalable timer queues into the xnpod_t > > structure instead of allocating it dynamically. This simplifies the pod > > initialisation and cleanup, which was not fully robust in this regard > > anyway. If a pod is now considered too large (but we are discussion > > kbytes here), allocating its buffer via xnarch_sysalloc would be an option. > > > > In case this patch is acceptable, I would suggest merging it before 2.2 > > due to the contained (minor) fix. > > Since this memory is specific to the data structure, its allocation > seems better by the data structure functions. It also make the binary > heap structure reusable for other purposes.
That's what I added the DECLARE_BHEAP_CONTAINER macro for. Sorry, did not mention this. The idea is to leave the allocation policy up to the user instead of enforcing it in the bheap layer. The current approach also implicitly excludes its usage from RT contexts, BTW. > > Could you explain why the current scheme is not robust ? > Given a SMP system where the allocation fails right in the middle of the per-CPU loop , cleanup will not be performed for already allocated heaps. Jan http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c?v=SVN-trunk#L432
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core