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