Hi all,

I was talking with Matt about the reentrancy stuff and replacing use of
the global cglob with a passed in cglob.  I wanted to outline the steps
required to get Csound reentrant as it looks to me.  I'm pretty sure I'm
not seeing the whole picture and the things that were already set in
motion by John and others, so feel free to correct me.

The current sources seem to already setup a lot of the work necessary,
as previously global data has been moved to the GLOBAL cglob.  I was
thinking the steps forward would be:

1)Use csound.c instead of jpff_glue.c.  csound.c is better set up to use
the API as the functions are all implemented.  Also, using ccsound.c
would be essential, as it uses the API.  This is important to do for
later steps.

2)Remove use of #defines that map to cglob, one by one, and do a global
find and replace to manually replace calls.  This basically does what
the cglob-mapping defines do using the preprocessor.

3)Rename cglob to something else, thus removing it from the global
scope.  This will be the big break.  After this, it's a matter of adding
the passing of cglob down the chain of function calls so that every
function that needs cglob will get it.  Renaming cglob would be
necessary as an intermediate step as csoundCreate, which currently
passes a reference to cglob, would pass the reference to the renamed
cglob.  This step sets up the functions of csound to handle being passed
in cglob, but does not yet remove the use of a GLOBAL * in the global
space.

4)Change csoundCreate to allocate a new GLOBAL * and remove the renamed
cglob from the global scope.  


I'm not sure if this was the original plan or what, I'm just wanting to
clarify if I've understood what's required correctly.  If this is
looking good, then I'll probably start on doing some of the global
find-and-replacing in step one, little by little. 

thanks all,
steven

> 2)Remove use of #defines that map to cglob, one by one, and do a global
> find and replace to manually replace calls.  This basically does what
> the cglob-mapping defines do using the preprocessor.
>
> 3)Rename cglob to something else, thus removing it from the global
>

i would just do 2 & 3 at once.  i just tried this with csound4 sources and
got over 3000 errors -- and it looks like that it only attempted compiling
about half the files..

so it may end up being A LOT of work to chance every function that uses an
ex-global variable to take a passed GLOBALS struct.  the other option
[as steven and i already discussed]
would be to just swap cglob structs on every API call -- you
would have to put up blocks for multiple instances, but it could be MUCH
easier than the other option...

-m

This was one of the early goals of the code-freeze, so I am very happy to see 
everyone ready to deal with what is clearly an arduous and time-consuming job! 
Getting return values from opcode fucntions is part of it of course, but 
re-parametrizing the functions is the other and even bigger task.

My one suggestion (in the absence of inspecting the sources just as I write) is 
that there will be many situations where a particular subset of global variables 
travel around together - not least, everything associated with the orch header 
info. These are worth wrapping into mini structures; in many cases there will be 
no need to pass the whole GLOBALS struct, but individual elements, or a 
particular group of them.  Conversely, I beleive there may be opportunities to 
eliminate many items from GLOBALS altogether, that really have no business being 
there (i.e. truly private to the internals of Csound), as their presence was 
merely a classic C way of avoiding writing functions structured into levels.

In short, I hope we can use this opportunity to further restructure the code, 
not just addrress the issue of re-entrancy.


Richard Dobson



Matt J. Ingalls wrote:
>>2)Remove use of #defines that map to cglob, one by one, and do a global
>>find and replace to manually replace calls.  This basically does what
>>the cglob-mapping defines do using the preprocessor.
>>
>>3)Rename cglob to something else, thus removing it from the global
>>
> 
> 
> i would just do 2 & 3 at once.  i just tried this with csound4 sources and
> got over 3000 errors -- and it looks like that it only attempted compiling
> about half the files..
> 
> so it may end up being A LOT of work to chance every function that uses an
> ex-global variable to take a passed GLOBALS struct.  the other option
> [as steven and i already discussed]
> would be to just swap cglob structs on every API call -- you
> would have to put up blocks for multiple instances, but it could be MUCH
> easier than the other option...
> 
> -m
> 
> 

I was thinking about this this morning and I think it might be possible
to replace the two OENTRY arrays with blanks and remove most of the
opcodes from compiling in the Makefile to then just concentrate on
finding where it'd be necessary to pass cglob down the functions.  

Either that, or doing this with Csound5 CVS stuff probably wouldn't be
as bad as non-necessary opcodes have already been moved by John to
opcode plugins.  

Thinking about it all more I think I'm more in line with Richard and
Michael regarding "biting the bullet" and just going ahead and trying to
find all the calls and passing things down the line.  It's going to be
better for multi-instance performance as well as two or more running
instances of csound won't block each other.  

steven


On Sun, 2003-11-16 at 00:24, Matt J. Ingalls wrote:
> > 2)Remove use of #defines that map to cglob, one by one, and do a global
> > find and replace to manually replace calls.  This basically does what
> > the cglob-mapping defines do using the preprocessor.
> >
> > 3)Rename cglob to something else, thus removing it from the global
> >
> 
> i would just do 2 & 3 at once.  i just tried this with csound4 sources and
> got over 3000 errors -- and it looks like that it only attempted compiling
> about half the files..
> 
> so it may end up being A LOT of work to chance every function that uses an
> ex-global variable to take a passed GLOBALS struct.  the other option
> [as steven and i already discussed]
> would be to just swap cglob structs on every API call -- you
> would have to put up blocks for multiple instances, but it could be MUCH
> easier than the other option...
> 
> -m
> 
> 

>>>>> "stevenyi" == stevenyi   writes:

 stevenyi> The current sources seem to already setup a lot of the work necessary,
 stevenyi> as previously global data has been moved to the GLOBAL cglob.  I was
 stevenyi> thinking the steps forward would be:

 stevenyi> 1)Use csound.c instead of jpff_glue.c.  csound.c is better set up to use
 stevenyi> the API as the functions are all implemented.  Also, using ccsound.c
 stevenyi> would be essential, as it uses the API.  This is important to do for
 stevenyi> later steps.

Whatever.  Still do not have a design for the API

 stevenyi> 2)Remove use of #defines that map to cglob, one by one, and do a global
 stevenyi> find and replace to manually replace calls.  This basically does what
 stevenyi> the cglob-mapping defines do using the preprocessor.

But there are two definitions.  Which one should be used?  The
rationale was to make the code look the same so people would un
destand it, and use the language facilities to deal with the
differences between loadable and fixed code.

 stevenyi> 3)Rename cglob to something else, thus removing it from the global
 stevenyi> scope.  This will be the big break.  After this, it's a matter of adding
 stevenyi> the passing of cglob down the chain of function calls so that every
 stevenyi> function that needs cglob will get it.  Renaming cglob would be
 stevenyi> necessary as an intermediate step as csoundCreate, which currently
 stevenyi> passes a reference to cglob, would pass the reference to the renamed
 stevenyi> cglob.  This step sets up the functions of csound to handle being passed
 stevenyi> in cglob, but does not yet remove the use of a GLOBAL * in the global
 stevenyi> space.

That will need more thought and design.

 stevenyi> 4)Change csoundCreate to allocate a new GLOBAL * and remove the renamed
 stevenyi> cglob from the global scope.  

When you have done 3

 stevenyi> I'm not sure if this was the original plan or what, I'm just wanting to
 stevenyi> clarify if I've understood what's required correctly.  If this is
 stevenyi> looking good, then I'll probably start on doing some of the global
 stevenyi> find-and-replacing in step one, little by little. 

Much of it was what I thought we were doing.


==John ffitch