I have mixed feelings about mini structures. I get your point about extra
junk in there and not needing the whole set, yet my experience tells me
keeping it all in one struct will make Csound easier to program and maintain
in future (oops, now this function needs member X added to its mini struct,
and this other function needs member X also added to ITS mini struct).

Could you please explain why you wish to distinguish between members of
GLOBALs and items private to Csound? How can Csound be a multiply
instantiable class if all required data is not referenceable through
GLOBALs?

I suggest it's better that all Csound state be in GLOBALs, but hidden, and
all Csound functions be in GLOBALs, but public.

Perhaps we can do something like this:

typedef struct CSOUND_INTERFACE {
int (Function1*)();
int (Function2*)();
} CSOUND_INTERFACE;

typedef struct CSOUND_STATE {
CSOUND_INTERFACE csound;
void *userdata;
int kr;
int sr;
...;
} CSOUND_STATE;

This allows CSOUND_STATE to be safely type cast to CSOUND_INTERFACE. Users
of the API only see CSOUND_INTERFACE, even though it carries a hidden
CSOUND_STATE:

CSOUND_INTERFACE  *csoundCreate(void *userdata)
{
    CSOUND_STATE *csoundState = (CSOUND_STATE *)
csoundAlloc(sizeof(CSOUND_STATE));
    csoundState->csound.Function1 = csoundFunction1;
    csoundState->csound.Function2 = csoundFunction2;
    ...
    csoundState->userdata = userdata;
    return (CSOUND_INTERFACE *)csoundState;
}

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Richard Dobson" 
To: "Csound Developers Discussion List" 
Sent: Sunday, November 16, 2003 5:34 AM
Subject: [CSOUND-DEV:3331] Re: Road to Reentrancy


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

  All I mean is that some of that data doesn't really represent state, but is 
merely "private" and often transient data passed from one function to another 
via a global variable. Variables that are used in only one or two files are 
cases in point. For example, "nrecs", and "ngotos". Variables that were 
originally static to one file but subsequently moved to GLOBALS are also cases 
in point. Some variables are in effect duplicates of data that is already 
available elsewhere. Anything that helps reduce the size of objects potentially 
helps enhance performance.

Many of these variables may not even need to survive at all when such things as 
the new parser, use of soundfile libraries etc come online. Others are surely 
read-only, and should be read through access functions only.

I like your your suggestion for an CSOUND_INTERFACE, aranging thinsg this way 
will also help clarify the restructuring process. I would then further suggest 
that as part of the anyway necessary restructuring of the code, that a lot of 
what is left can probably be removed through a process of voluntary redundancy, 
so that in the end CSOUND_INTERFACE is all there is. In short, I don't think the 
Csound state requires quite as much stuff as we currently have.

A case in point is a variable such as "currevent", which is a pointer to an 
EVTBLK (so we are stuck with the definition of that). Scanning through my 
version of Csound (4.23), the only elements of it that opcodes  are interested 
in are "strarg", which is a string (may need to be Unicode one day), and the 
list of pfields.  Arguably both are read-only. It is set in playevents() and if 
it is passed to each opcode as an argument (which would be more self-documenting 
if nothing else!), it is IMO very debatable whether it needs to be in GLOBALS at 
all. So many programmers have complained about the obscureness and 
undocumentedness of the code, and this is just the sort of change that will not 
only modularise the code more and economise on the size of GLOBALS, but obviate 
those criticisms too.




Richard Dobson



Michael Gogins wrote:

> I have mixed feelings about mini structures. I get your point about extra
> junk in there and not needing the whole set, yet my experience tells me
> keeping it all in one struct will make Csound easier to program and maintain
> in future (oops, now this function needs member X added to its mini struct,
> and this other function needs member X also added to ITS mini struct).
> 
> Could you please explain why you wish to distinguish between members of
> GLOBALs and items private to Csound? How can Csound be a multiply
> instantiable class if all required data is not referenceable through
> GLOBALs?
> 
> I suggest it's better that all Csound state be in GLOBALs, but hidden, and
> all Csound functions be in GLOBALs, but public.
> 
> Perhaps we can do something like this:
> 
> typedef struct CSOUND_INTERFACE {
> int (Function1*)();
> int (Function2*)();
> } CSOUND_INTERFACE;
> 
> typedef struct CSOUND_STATE {
> CSOUND_INTERFACE csound;
> void *userdata;
> int kr;
> int sr;
> ...;
> } CSOUND_STATE;
> 
> This allows CSOUND_STATE to be safely type cast to CSOUND_INTERFACE. Users
> of the API only see CSOUND_INTERFACE, even though it carries a hidden
> CSOUND_STATE:
> 
> CSOUND_INTERFACE  *csoundCreate(void *userdata)
> {
>     CSOUND_STATE *csoundState = (CSOUND_STATE *)
> csoundAlloc(sizeof(CSOUND_STATE));
>     csoundState->csound.Function1 = csoundFunction1;
>     csoundState->csound.Function2 = csoundFunction2;
>     ...
>     csoundState->userdata = userdata;
>     return (CSOUND_INTERFACE *)csoundState;
> }
> 

I was looking at csound.c and there's some references to the OPARMS
struct O.  Where does this fit in to the csound system?  It seems
something separate outside the API and the engine, something a host
would use to configure the engine before running, but I don't know how
integrated the console csound code is with the engine, and I don't know
if it's considered Csound state data or what.

Any thoughts on this appreciated!
steven



On Sun, 2003-11-16 at 09:41, Michael Gogins wrote:
> I have mixed feelings about mini structures. I get your point about extra
> junk in there and not needing the whole set, yet my experience tells me
> keeping it all in one struct will make Csound easier to program and maintain
> in future (oops, now this function needs member X added to its mini struct,
> and this other function needs member X also added to ITS mini struct).

The O structure is original Csound, and predates by years all this API
stuff.  When I created the single structure to hold global data I
thought that it was best not to disturb the existing running system
too much, so I left O alone.  It could be incorporated into a single
structure and probably should be at some stage.  At present there is a
pointed from cglobs to O anyway.

==John ffitch