Workspace Allocate in capture

[Chris Johns]

Joel Sherrill wrote:
> 
> 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.
> 

   rtems_extension_workspace_allocate
   rtems_extension_workspace_free

> 
> OK. Please submit a patch.
> 

I will commit on the cvs mainline for the simple fix.

> 
> Create is better.
> 

Yes and given the iterate over threads, this can be done.

> 
> 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 problem for the capture is engine is almost a GC type operation. You 
  capture a thread being created and deleted but dump it much later. The 
capture engine needs to hold the task's data (it's private data) until 
the capture buffer does not contain a reference. Once displayed the 
memory can be freed.

> 
> 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 ...
> 

Great. I will look at this.

One problem still exists. The capture engine is started by a user with a 
call from a task. If I scan the list and use malloc to hold task data, 
when a task is created and I use workspace allocate, do I have to know 
the source of the memory to return it to the correct heap ?

Can I call the workspace free from a task ? Whan can workspace free be 
called ?

-- 
  Chris Johns, cjohns at cybertec.com.au