Workspace Allocate in capture
joel.sherrill at OARcorp.com
Fri Oct 3 11:21:58 UTC 2003
Chris Johns wrote:
> Joel Sherrill wrote:
>> > Given _Workspace_Allocate is to be used in task create and task
>> create > can be called by a user extension, should we provide an
>> interface that > is not the score one being used ?
>> Sounds like it might not be a bad idea if we are encouraging extensions
>> to allocate during create and only from the workspace. It is also
>> something that would be documentable that way. Right now, it is
>> a bit ugly.
> What should the interface look like and where should it live ?
Just a thought .. rtems_extension_allocate_from_workspace? We
might even then be able to put in some checks to ensure that it is
only called from the create extension.
>> > FYI I used _Workspace_Allocate in the capture engine.
>> I saw that and wondered when each call to allocate or free occurred.
>> I should have asked then. SO go ahead and tell us when each is call.
>> Then I can see if we need to worry or not. :)
> I suspect we need to worry.
> The first case is basically wrong and should be changed to
> malloc/free. This is creating a capture control. This should only be
> called by other threads, eg the monitor.
OK. Please submit a patch.
> The second is a little harder. The capture engine does not learn when
> it starts what tasks are currently running. As a result, a create
> (ok), start (?), or restart (?) or task switch (?) will perform a
> _Workspace_Allocate if capture does not know about the task.
Create is better.
> The capture engine frees when closed (this code could be better as
> ints are masked when doing this), or a control is deleted. I currently
> do not delete the memory for a task. The capture buffer could contain
> a reference to a deleted task. That maybe needed.
You are right.. this is harder. When you delete an extension, the
extension doesn't get the
opportunity (safe or not) to do any cleanup.
> The reason did not scan the task list is no interface exists part from
> digging into the score interfaces. Maybe this needs to be looked into
> as well. If an interface exists then the capture would be functionally
> better, and the workspace allocations outside of task create would go.
There is now rtems_iterate_over_all_threads() which might be of help.
It is in score/src/iterateoverthreads.c.
I wrote it to support sync() and thought that it would help other
libraries like this and cpu usage ...
More information about the users