Another restriction would be no multiplicity, i.e. only one pike interpreter per process.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-23 16:51: Subject: Embedding Pike into C/C++ game
I think the biggest problem is that no one is making a list of the actual problems that should be solved. To me it (since I know so little about the backend, memory management etc) it feels like it shouldn't be that hard to add pike_init and pike_exit that does what main does and then begin to call Pike code (possibly with a set of restrictions like no threads and no call_outs).
/ Martin Nilsson (saturator)
Not really. And we are talking about the fast-hack method.
Adding multiplicity support requires changing code in more or less all modules and some parts of the pike core.
It's very common to have static variables for cache purposes (if nothing else the constant strings)
/ Per Hedbor ()
Previous text:
2004-02-24 01:01: Subject: Re: Embedding Pike into C/C++ game
On Mon, Feb 23, 2004 at 05:10:28PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Another restriction would be no multiplicity, i.e. only one pike interpreter per process.
This would be very sad restriction...
Regards, /Al
/ Brevbäraren
On Tue, Feb 24, 2004 at 01:05:02AM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
Not really. And we are talking about the fast-hack method.
Well, in this case, if Pike interpreater can be run in separate thread (i.e., will not interfere with main process), this should be sufficient.
Regards, /Al
I think there is something I understand. Since it has been said that there is a global interpreter lock when executing Pike code, what would this change then ?
Does this mean that the interpreter lock is only local to the current intrepreter but that other intrepreters can run simultaneously anyway in the same process (by using thread_create ?) ?
Another restriction would be no multiplicity, i.e. only one pike interpreter per process.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-23 16:51: Subject: Embedding Pike into C/C++ game
I think the biggest problem is that no one is making a list of the actual problems that should be solved. To me it (since I know so little about the backend, memory management etc) it feels like it shouldn't be that hard to add pike_init and pike_exit that does what main does and then begin to call Pike code (possibly with a set of restrictions like no threads and no call_outs).
/ Martin Nilsson (saturator)
The references to the interpreter lock, and serveral other things, are through global variables. Because of this only one interpreter can (currently) exist within a single address space.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-24 01:17: Subject: Re: Embedding Pike into C/C++ game
I think there is something I understand. Since it has been said that there is a global interpreter lock when executing Pike code, what would this change then ?
Does this mean that the interpreter lock is only local to the current intrepreter but that other intrepreters can run simultaneously anyway in the same process (by using thread_create ?) ?
Another restriction would be no multiplicity, i.e. only one pike interpreter per process.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-23 16:51: Subject: Embedding Pike into C/C++ game
I think the biggest problem is that no one is making a list of the actual problems that should be solved. To me it (since I know so little about the backend, memory management etc) it feels like it shouldn't be that hard to add pike_init and pike_exit that does what main does and then begin to call Pike code (possibly with a set of restrictions like no threads and no call_outs).
/ Martin Nilsson (saturator)
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
David Gourdelier -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Per Hedbor () ＠ Pike (-) developers forum