Workspace Allocate in capture

[Joel Sherrill]

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

--joel