Hello Christoph,
I tried Cint multithreading with your scheme on Linux. It basically seems
to work, but has some problem. Let me explain what I've found.
# When it works
Cint multithreading works with multiple shared library object if no
further shared libraries are loaded by cint. This is illustrated as
follows.
main program ------> libcint1.so
------> libcint2.so
------> libcint3.so
. .
Static variables in libcint.so are independently maintained and
multithreading works as expected.
# When it does not work
However, if further shared library is loaded by cint, it has problem
resolving symbols in libcint. For example,
main program ------> libcint1.so -------> otherlib.so (G__cpp_XXX.C)
<--------
tries to find functions
in libcint1.so, but it fails
suppose otherlib.so is created by makecint and it contains G__cpp_XXX.C.
Code in G__cpp_XXX.C uses functions in libcint.so. otherlib.so is loaded,
for example, by '#include "otherlib.so"' At dictionary initialization,
it fails to find symbols in libcint.so. Even if it finds a symbol, it
is not guaranteed that the symbol comes from right libcint?.so, because
you have multiple of them. Someway, this causes segmentation violation.
I can think of a way to solve this problem. However, we will lose
compatibility from existing version which is not tribial.
Let me think for a while.
Thank you
Masaharu Goto
>Hello Masaharu,
>
>Actually the idea was of a collegue of mine, here in TTI. On the one hand, w
e
>know it a 'not very elegant' (to say the least) workaround, but on the other
>hand - I can't think of a reason why it shouldn't work. We need to use this
on
>most platforms, and I already tried this on Linux/gcc-3.0-snapshot,
>Solaris/CC5, and NT4/msvc. On Solaris it already seems to work quite well.
>
>
>I read somewhere in the CINT documentation that you recommend people to
>'register' when they are using cint.
>So I would like to register myself and my employer as a cint user :)
>
>I am using cint as part of a larger C++ framework that our company uses as a
>basis to develop our applications. TTI-Telecom is a software company, with +-
>500 employees. We are selling solutions (servers + software) to telephony
>companies all over the world. We need 'scripting capabilities' in our
>framework, and we intend to use cint for this. I am a programmer working at
>TTI, and my job is currently to implement the scripting capabilities of our
>framework.
>
>Thanks a lot :-)
>Yours,
>
>Christoph Bugel
>TTI Telecom
>www.tti-telecom.com
>
>
>
>On Thu 2001-05-10, Masaharu Goto wrote:
>> Hello Christoph,
>>
>> This is a very interesting idea. As far as I know,
>> nobody has tried it. Whether or not this works depends
>> on a shared library symbol resolution scheme in your
>> operating system. If the operating system always resolves
>> symbols within own shared library, it works. However,
>> if symbols are resolved among multiple libraries, this won't
>> work. I have a feeling that this works for Windows and
>> IBM AIX, but not for most of the other platforms.
>>
>> I'll try this myself as soon as I can find my time.
>>
>> Will you teach me which platform are you using?
>>
>>
>> Thank you
>> Masaharu Goto
>>
>>
>> >Date: Thu, 10 May 2001 13:24:46 +0300
>> >From: Christoph Bugel <chris@uxsrvc.tti-telecom.com>
>> >To: Valeri Fine <fine@bnl.gov>
>> >Cc: roottalk@pcroot.cern.ch, MXJ02154@nifty.ne.jp
>> >Subject: Re: [ROOT] CINT thread safety hack?
>> >
>> >Hi Valeri,
>> >
>> >Actually I don't use ROOT at all! (I installed it, out of curiosity of
>> >course, and was very impressed) but I 'just' need a C++ interpreter, and
>> >this mailing list is for CINT as well. (I think (?)). My shared library
>> >doesn't contain ROOT. I just download the most recent cintX.Y.Z.tar.gz
>> >every now and then from root.cern.ch, and compile it. (and play around
>> >with the Makefiles as needed to create a shared library). You mentioned
>> >the 'CINT Thread' - with other threads sending messages to it. I don't
>> >need other thread talking with the CINT thread. But on the other hand,
>> >I need more than one 'CINT thread'!! Each CINT is totally independent,
>> >and runs a totally different C++ function. You are right to ask - why
>> >don't I do it in different processes, when there is nothing to share
>> >anyway. The answer is that this code has to fit into an existing
>> >framework with a very object oriented && multithreaded architecture, it
>> >is just a given fact that I have to comply with..
>> >
>> >I still didn't run it under gdb, admittedly.
>> >
>> >I understand that cint does dynamic loading and unloading of dlls at
>> >runtime. But since I don't use those features (I think I don't -- I
>> >don't use any libraries such as iostream, STL, etc, and I dont do any
>> >#pragma compile or any other #pragma, I just run a C++ function from a
>> >file -- nothing 'dynamic') I hoped I could succeed to run simultaneous
>> >CINT threads without a problem, provided I could isolate them from each
>> >other by loading them into different memory locations (as described
>> >below) -- effectively multiplexing their global variables. I know this
>> >has been discussed before, but my boss wanted to try out anyway. After
>> >all, in theory it should (probably) work. Actually, it already works,
>> >some times.. I managed to load two 'instances' of cint, each running a
>> >different program, only right now this succeeds sometimes and crashes
>> >sometimes :(
>> >
>> >Christoph
>> >
>> >
>> >
>> >On Wed 2001-05-09, Valeri Fine wrote:
>> >
>> >> 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 al
l
>> >> 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 stati
c
>> >> > 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 sinc
e
>> >> > cint generates random temporary filenames two thread won't use the sam
e
>> >> > 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:46 MET