Re: Embeddable and Extensible Languages

"PlayDough" <petela@gocougs.wsu.edu>
15 Jan 2005 20:57:49 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Embeddable and Extensible Languages lhf@csgpwr1.uwaterloo.ca (2005-01-14)
Re: Embeddable and Extensible Languages Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2005-01-14)
Re: Embeddable and Extensible Languages thant@acm.org (Thant Tessman) (2005-01-14)
Re: Embeddable and Extensible Languages hombre@gmail.com (Tom Verbeure) (2005-01-15)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-15)
Re: Embeddable and Extensible Languages kenrose@tfb.com (Ken Rose) (2005-01-15)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-15)
Re: Embeddable and Extensible Languages thant@acm.org (Thant Tessman) (2005-01-22)
Re: Embeddable and Extensible Languages jc.lelann@wanadoo.fr (Jean-Christophe Le Lann) (2005-01-22)
Re: Embeddable and Extensible Languages gneuner2@comcast.net (George Neuner) (2005-01-24)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-25)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-25)
Re: Embeddable and Extensible Languages lex@cc.gatech.edu (Lex Spoon) (2005-01-25)
[1 later articles]
| List of all articles for this month |

From: "PlayDough" <petela@gocougs.wsu.edu>
Newsgroups: comp.compilers
Date: 15 Jan 2005 20:57:49 -0500
Organization: http://groups.google.com
References: 05-01-040
Keywords: interpreter, design
Posted-Date: 15 Jan 2005 20:57:49 EST

PlayDough wrote:
> packages/add-ons). Perferably it has a reasonable footprint, it
> portable across platforms (Linux and Win32), and support for
> multiple contexts.


I wasn't abundantly clear on the above point (others have asked "what
do I mean exactly"), so I want to clarify the above point.


I would like to find a language with a reentrant interpreter. But
even this isn't totally accurate. Perhaps a C++ example might clear
up what I'm trying to do.


For example, I create a class:


class X
{
public:
X(const std::string& script_file);
void Run(void);


private:
Interpreter_context ctx;
};


And in the constructor, I do something like:


X::X(const std::string& script_file)
{
interp_init();
interp_create_context(&ctx);


load_script(&ctx, script_file);
}


void X::Run(void)
{
run_script(&ctx);
}


Now in the application, I would instantiate class X several times,
however, in separate threads. I don't have control over the thread
creation mechanism, nor the instantiation of the classes. I only have
control over the class I create.


However, as an example, I can do the following:


void* thread1(void* arg)
{
X x1("script1");


x1.Run();
}


void* thread2(void* arg)
{
X x2("script1");


x2.Run():
}


int main(void)
{
pthread_t thr1, thr2;


pthread_create(&thr1, 0, thread1, 0);
pthread_create(&thr2, 0, thread2, 0);


pthread_join(thr1, 0);
pthread_join(thr2, 0);
}


Nearly all the languages I've looked at have some soft of global,
static storage that prevents this type of mechanism from working. For
example, Ruby has ruby_init(). Ignoring issues of callback (language
extensions that call class methods), is there a language that
guarantees that x1's interpreter and x2's interpreter will not collide
in threads?


This is why I'm leaning towards Lua. It seems well behaved in this
respect.


Thanks,
Pete


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.