Workspace Allocate in capture

Chris Johns cjohns at cybertec.com.au
Fri Oct 3 02:50:22 UTC 2003


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 ?

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

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.

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.

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.

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




More information about the users mailing list