[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Workspace Allocate in capture
- Date: Sat, 04 Oct 2003 08:12:53 +1000
- From: cjohns at cybertec.com.au (Chris Johns)
- Subject: Workspace Allocate in capture
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.
> 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
Chris Johns, cjohns at cybertec.com.au