Ross Bencina wrote:
>
> Michael Gogins wrote:
>
> >The current design of sfront does not lend itself to multiple-instance
> >servers, which Ross is talking about here. sfront is a "process" and
> assumes
> >that all static objects occur only once per process. The operating system
> >can copy static objects for different PROCESSES served out of the same code
> >(program text, technically speaking) but not, without additional coding,
> for
> >different THREADS or different INSTANCES.
>
> >
> >I was assuming that even a one-instance sa.dll is better than none.
> Changing
> >the design to support multiple instancing would, in practice, almost
> >necessitate a complete rewrite and would most naturally be done in C++, not
> >C. Presumably any really commercial implementation of SAOL would do this.
>
> I would agree that 1 is better than none, but unless you have an MP box,
> running multiple instances in separate threads/processes is probably going
> to cost as much performance as adding a level of indirection (see below).
> Also I think a commercial version would largely be written in asm.
>
> Just looked at the code... there would be a fair amount (but not an
> impossible amount) of work converting sfront to access globals via an
> explicit "this" ptr, and even if you did (either explicitly using C or
> implicitly using C++) people running a single instance might take a
> performance hit from pointer indirection if you made global mods...
>
> There are good reasons not to export a C++ interface from the dll: On most
> if not all platforms there is no standard name mangling / calling
> conventions for C++ objects (method pointers). And generating C++ from
> sfront seriously limits it's applicability...
>
> That said, it seems like the easiest thing to go would be to have sfront
> _optiononally_ spit out a C++ class that wraps the whole shebang (everything
> in sa.c). All of the functions would effectively be declared inline so you
> don't have to modify sfront to generate prototypes or separate
> class/namespace definitions. Here's how to do it:
>
> //1. put this at the top of sa.c (after the externs for system functions):
> class SaPlugin{
> public:
>
> //2. put this at the end of sa.c:
> };
>
> //3. move in place initialisation for the globals such as:
> short *asys_obuf = NULL; /* pointer to output sample buffer */
> long asys_osize = 0; /* size of output buffer */
> long obusidx = 0;
>
> //into system_init:
> short *asys_obuf; /* pointer to output sample buffer */
> long asys_osize; /* size of output buffer */
> long obusidx;
>
> ...
>
> void system_init(void){
>
> asys_obuf = NULL;
> asys_osize = 0;
> obusidx = 0;
>
> };
>
> This would initialise these variable properly whether they were C globals or
> C++ instance variables, and would be backward compatible with the non class
> based c generated code.
>
> // 4. Replace main(argv,argc) with the SFrontPlug*() functions
>
> Note that I'm not proposing this as an "object oriented" solution, trying to
> set up proper c++ constructors and destructors, private or protected
> variables etc.. Just wrap the whole thing in a class (a C++ struct might
> even capture the intent better), then everything that what was once a global
> variable becomes an instance variable and you can stamp out multiple
> instances without impacting most of the code (so generating the non class
> version will be just as easy).
>
> What do you think?
This should do the trick, and as you say it would be nice to have it as an option.
-- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 .........................................................................
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:35 EDT