Embedding ruby in a multi-threaded host application

(Olivier Mascia) #1

Hello,

I would like to host ruby interpreter in an application to bring in a superb scripting language to the app. Though I read that now the interpreter makes use of global variables for its own state, excluding it from being hosted in a multi-threaded application which cannot afford a total mutual exclusion of all its threads when calling the interpreter. In this application, dedicating a single thread to ruby and having other worker threads queue themselves for access to the single thread hosting ruby is not possible too.

The application would need multiple of its threads to have access to a private instance of the whole interpreter, with complete state separation between all these instances.

Has someone more information on the ruby's developers goal regarding this? Is this something being considered? Is this being worked on? Planned for a future release? For *the* next release?

Thanks !

···

--
Olivier Mascia

(Olivier Mascia) #2

Hmm. I could not find evidence that this is being worked on, nor even that this is something really considered for the future (reasonable future - not in 2 years).

I think it will be probably wiser for me to adopt Lua instead of Ruby at least on this project, even though of course both beasts aren't equivalent and even though I had an irrational personal preference to use Ruby. Lua seems to fit the embedding need perfectly : it has been designed for that.

···

Le 23-août-05 à 14:24, Olivier Mascia a écrit :

I would like to host ruby interpreter in an application to bring in a superb scripting language to the app. Though I read that now the interpreter makes use of global variables for its own state, excluding it from being hosted in a multi-threaded application which cannot afford a total mutual exclusion of all its threads when calling the interpreter. In this application, dedicating a single thread to ruby and having other worker threads queue themselves for access to the single thread hosting ruby is not possible too.

The application would need multiple of its threads to have access to a private instance of the whole interpreter, with complete state separation between all these instances.

Has someone more information on the ruby's developers goal regarding this? Is this something being considered? Is this being worked on? Planned for a future release? For *the* next release?

--
Olivier Mascia

(Lyndon Samson) #3

Sometimes Thread Local Storage is a possible work around for global variable
issues.

With Windows you can achieve this in two different ways:

   - Declare a variable as thread local
   Say you have a global variable *int g_TheCounter;*. You can write *
   _declspec(thread) int g_TheCounter;*. This tells the compiler to tread
   the variable as thread local.
   - Use dynamic thread local storage
   There is a special API The functions (*
   TlsAlloc/TlsFree/TlsSetValue/TlsGetValue*).
   
   *TlsAlloc/TlsFree* Allocate an index that is used to access one thread
   local storage value. This index must be placed into a global variable (it is
   a read only value since). It is used with the *TlsSetValue/TlsGetValue
   * functions to modify the thread local storage variable. For more
   details see the Knowlede base article Q94804 "Thread Local Storage overview
   
http://www.michaelmoser.org/tlssupp.htm