I did embark on just this some while back, adding in lots of init functions, and
indeed got Csound running re-entrantly for most of the main opcodes, but I ran
out of steam after a while (local statics are a particular problem!). Also, John
Fitch told me  a few months ago that
 a few of the things I had done weren't quite right (but I don't yet know what
those are!); however, most of what I did is still in the published sources,
commented out. I have a lot of other work on at the moment, but I do want to go
back to this exercise at some point. Once it is done, there is the chance for
some ~very~ snappy user interfaces - and it would benefit all platforms. 

It would help if people adding new opcodes gave a moment to add init functions
(and preferably memory de-allocation functions too), avoided local statics, and
so on. Once the modules are re-entrant, there is a sporting chance the framework
code can be made so too.

Perhaps we could co-ordinate?

Richard Dobson

Michael Gogins wrote:
> 

> 
> The main obstacle is that Csound is designed as a process that starts, runs
> an orc and sco, and exits. It cannot restart, its code is not re-entrant. If
> this were fixed I would make Csound into a COM server myself. Anyone who
> wants to work with me on this, please do!