[C++-sig] Re: Interest in luabind

[Rene Rivera]

[2003-06-18] David Abrahams wrote:

>Rene Rivera <grafik666 at redshift-software.com> writes:
>
>> [2003-06-18] David Abrahams wrote:
>>
>>>Python can handle multiple interpreter instances too, but hardly
>>>anyone does that.  In any case, it still seems to me to be a handle
>>>to global state.
>>
>> Perhaps because Python has a higher interpreter cost? 
>
>I'm not really sure why.  What's an "interpreter cost?"

The time and space required to initialize/create a context sufficient for
executing some scripted code independent of any other such context.

>> The thing is it's the recomended way to do things in Lua.
>>
>>>> So having a single global var for that is not an option. 
>>>
>>>Why not?  I don't get it.  Normally any module's initialization code
>>>will be operating on a single interpreter, right?
>>
>> No. The LuaState is the complete interpreter state. So to do bindings, or
>> anything else, you create the state for each context you are calling
>> in.
>
>"Context", possibly meaning "module?"

No I meant execution context in this case. As in that of a thread. Hence my
use case below.

>If so, I still don't see a problem with using namespace-scope
>variables in an anonymous namespace (for example).
>
>> There's no limitation as to matching the state to anything else
>> other than the calling context. For eaxmple I could create a set of
>> states, say 20, and have a pool of, say 50, threads that all "share"
>> those on an as needed basis. Something like this is in fact my
>> current need for Lua.
>
>Wow, cool and weird!  Why do you want 20 separate interpreters?

Because they may be 20 separate Lua scripts running at a time. My current
product has the ability for users to specificy script code that runs on the
server. And the server can have some bounded set of execution threads to
handle the actions. But only a subset of those will be executing script
code.

Here's a comparable use case. Imagine you want to make it possible to write
scripting capabilities to a web server. It runs a varying number of threads
to handle client requests any of which can possibly run some script code. So
you write up a common interpreter state pool, just like you have a thread
pool. If a thread needs to execute some script code it grabs one of the
interpreter state objects and calls the interpreter code with the state and
the script.

>> Ah, well, there's the rub ;-) They can initialize concurrently. And
>> to make it more interesting the same state can be used by different
>> threads (but not at the same time) from time to time.
>
>If the same module can be initialized simultaneously by two separate
>interpreters, I can see that there might be a problem.  Of course, one
>could put a mutex guard around the whole module initialization, but
>the people who read the ASM would probably be upset with that.

<caveat>
I'm talking Lua4 here so my info may be outdated. I know there's some new
stuff to handle sharing of state. I'll look into the luabind code to see how
it's doing things.
</caveat>

If one needs for script code to execute concurrently then one has to
initialize the modules into (clasic idea of intern) each interpreter state.
So if requiring that all such initializations execute serialy solves the
problem, that's fine IMO. Unless the people who read the ASM intend to do
initializations all the time they can live with the mutex. After all in such
cases you pool those initilizations ahead of time as I mentioned above. 


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq