| Nicola Bernardini wrote:
[snip]
> I think that certainly more consistent structuring of the Csound code
> with elimination of globals and statics (why statics? they are quite
> fine in my opinion) would be a nice thing to do
I agree that in a single execution environmemt statics are fine. However, in a
re-entrant environment, such as a GUI framework, which I think would be the main
beneficiary of a move to dlls, at the very least, statics need to be reinitialized.
This is easy enough with global statics, but statics local to a function (such as
call counters and init flags) need special handling.
In many cases, statics are simply used to transfer data betweeen functions, and with
a bit of careful coding, can be eliminated, to, I feel, the general betterment of
the code.
A particular problem can arise with static pointers, which are given dynamically
allocated memory. In some cases, these are const singletons (eg the sine wave for
adsyn, and the sinc table in dsputil.c), which only need to be created once, at the
framework level, and are thereafter read-only. In other cases, they are not
re-entrant within a process (ie are not shareable or thread-safe). There is a good
example of this in linevent.c. In a GUI framework, it is conceivable that more than
one Csound thread can be launched at a time (eg a lengthy pvanal while contuning
work compiling orchestras) - this requires Csound, and any dlls it uses, to be
reentrant within a single process space.
The GEN functions all use local statics (they are all " void func(void)" - no
inputs or outputs, only 'side-effects'!). They are not singletons or const, as the
score has the power to destroy one and reassign. However, they ~could~ be shareable,
especially if a reference count is maintained so that identical f-tables do not have
to be created multiple times. This again is a natural task for a framework.
In a framework, a situation could easily arise in which a user has loaded an orc
file, which is duly parsed. There is however a problem with the score file, or the
user simply cancels performance, and edits the score file. The latter obviously
needs to be re-scanned, but there is no concomitant need to re-scan the orchestra,
certainly no need, for example, to reload dlls. A Csound GUI framework thus will act
as a simple form of make facility, reinitializing only those components which need
it.
I have just found a problematic static relating to MIDI controllers. It is not
initialized, or ever assigned to, but it is used in one function, as the index into
an array, and to both free a block in that array, and allocate to it. If anyone
experiences random problems with MIDI controller opcodes (in 3.47), the cause is
most likely here.
Richard Dobson
|