Re: [Xenomai-core] [RFC] define your own pipe heap

[Dmitry Adamushko]

[EMAIL PROTECTED] wrote on 22.11.2005 11:21:09:

> Jan Kiszka wrote:
> > ...
> > A patch says more than thousand words. ;)
> >
> > As a first approach, I picked the second variant and implemented a new
> > function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
> > rt_pipe_free so that the right pool is used by them.
> >
>
> I thought about this variant again, and it seems to me rather unsafe in
> case some buffer allocation takes place between rt_pipe_create and
> rt_pipe_setpool. So, here is a patch which extends rt_pipe_create with a
> new argument poolsize instead.

I haven't read the patch thoroughly yet so just a few common remarks. IMHO, the interface would be much clear in case a rt_pipe_create() is extended since:

- we avoid a misuse when a rt_pipe_alloc() is called with an old pool but rt_pipe_free() (explicitly or implicitly internally) is called with a new one;

- rt_pipe_setpool() can be successfuly called only once and a user must care that:
o  either this is next call after a pipe has been created;
o  or all messages allocated from the "old" pool have been freed by that moment (otherwise we need to extend a pipe::message interface so that every message knows the exact pool it has been allocated from and, moreover, implement the reference counting so that a pool object exists as long as there is at least a reference on it - and we don't need that complications).

So, yep, adding an additional parameter to the rt_pipe_create() would be a better solution. My humble 2 cents :o)

Once I thought about an interface that allows to "attach/detach" an existing RT_HEAP object to any pipe/queue/maybe_smth_else but here we would need to extend the underlying mechanisms as I mentioned above.
And likely, such an interface is not something of big avail for strict real-time environments. Keep it simple instaed :o)


---
Best regards,
Dmitry