Hi, Chrisoph
>
> I am currently trying out an *ugly* workaround to run multiple cint's
> in multiple threads. They don't need to share anything between each
> other. Each cint thread will just load a some file and execute a few C
> functions from it. If anyone can point out why the following method
> will break - please do!
The question is which thread is responsible for the dictionaries of all
ROOT classes?
Did you assume each your share library will include the entire ROOT ?
Then why do you need all of this, it is much simpler just to run the
separate
processes.
On another hand the Windows version of ROOT is 4 threads application by
now.
One of them drives "CINT", others are to sent mesages to the "Cint" thread.
Somehow it works,
> The workaroud is as following: I compiled cint into a shared library
> (.so). My process copies this cint.so into a few identical copies with
> *different* names -- one for each thread. for example cint.1.so,
> cint.2.so, cint.3.so, etc. Then, each thread does a dlopen on its own
> copy of cint and looks up (dlsym) the symbols it needs (like
> G__init_cint, G__loadfile, G__exec_text, etc). Because the dlls have
> different names, the code will be entirely loaded each time, so
> cint.1.so and cint.2.so are each loaded into another memory location,
> and all variables used by cint are multiplexed - even global and static
> ones.
If variables are to be multiplexed then why do you need the threads.
I am guessing you do want your threads share information via common
memory.
> This method worked for some simple tests (without cint). This method
> does not protect shared resources such as files, but then I think since
> cint generates random temporary filenames two thread won't use the same
> filename anyway. It almost works for me already, only I just got a
> segfault, and I wondered if I forgot something. (Usually these
> segfaults are my own fault) did I miss something important?
Did you try this under debugger. What did it say ?
Valeri
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:44 MET