Hi Nick,
This problem can be seen on either platform.
The main factor here is the CPU speed and the current system "tick rate"
rather the type of the OS. I'd like to mention the "tick rate", i.e. the
minimal period of the time the system dispatches to some dedicated
thread / process is an internal system parameter. This may have
different default value for different brands and can be adjusted also.
If your system is quick enough, and the tick rate is large enough to
perform the loading and initialization of the DLL within one tick then
you see no problem. It is obvious when you start the system for the
first time it is used to take the significant longer to make the
application up. When you start it for the second time then almost all
DLL's have been cached into the memory and the application needs less
time to load it. This explains why you see the problem with the first
start only.
What about the system console hang at ROOT logoff.
You are correct attributing this problem to the multi-thread nature.
Unfortunately the cause of this is not as obvious as that above. What
is clear some class dtor's are not called when the application is being
closed down especially those from the non-main thread. So the thread is
just terminated with no say.
At the moment I can not say whether it is "by design" or by MS mistake.
It would be nice to know how the class dtors are handled by UNIX OS's
with multi-thread applications ( I am wondering if Go4 people may
educate us)
If this is "the common design" then ROOT has to choose some "thread
model" (see for example
http://my.execpc.com/~gopalan/com/com_threading.html ) and maintain its
own list of the threads created and clean it up before calling any
terminate method.
Just my 2 cents
Best regards, Valeri
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]
> On Behalf Of Nick van Eijndhoven
> Sent: Wednesday, October 30, 2002 3:36 AM
> To: pcanal@fnal.gov
> Cc: roottalk@pcroot.cern.ch
> Subject: Re: [ROOT] Latest problem on windows explained! (Really!)
>
> Hi Philippe,
> Congratulations !
> This is really very good news.
> As far as I understand your analysis, some of the ROOT facilities
> (you mention gROOT->LoadClass) are not protected for multi-thread.
> Could the problem of the infinite loop after .q when a TBrowser had
> been opened also be related to a somewhat similar 'disease' ?
> Also this problem is only seen on windows (as far as I can check
> mainly/only on win98).
>
> Cheers,
> Nick.
>
> --
> Dr. Nick van Eijndhoven mailto:nick@phys.uu.nl
http://www.phys.uu.nl/~nick
>
------------------------------------------------------------------------
--
> Org.: Utrecht University, Faculty of Physics and Astronomy
> Address: Princetonplein 5, NL-3584 CC Utrecht, The Netherlands
> Phone: +31-30-2532331(direct) +31-30-2531492(secr.) Fax:
+31-30-2518689
> CERN: +41-22-7679751(direct) +41-22-7675857(secr.) Fax:
+41-22-7679480
> Offices: Buys Ballot laboratory Room 710 (Utrecht) B23 1-020 (CERN)
>
------------------------------------------------------------------------
--
>
>
> Philippe Canal wrote:
> >
> > Hi,
> >
> > I understood (and fixed) the problems on Window 98, XP, 2000 where
ROOT
> > was mysteriously, randomly crashing or giving error messages like
'this
> > "text file name" is a binary file' or other weird behaviors.
> >
> > This problem was only appearing at startup time and only on Windows.
> >
> > The code will be fixed shortly in the CVS repository.
> >
> > Cheers,
> > Philippe
> >
> > And now for the gory details
> >
> > In the constructor of TRint::TRint we had:
> >
> > ProcessLine("#include <RtypesCint.h>");
> >
> > gROOT->LoadClass("TGeometry", "Graf3d");
> > gROOT->LoadClass("TTree", "Tree");
> > ....
> > ProcessLine(Form(".L %s",logon),kTRUE);
> >
> > The problem comes from the fact that on Windows ProcessLine has the
> > execution of its CINT part delayed (1st problem) while
gROOT->LoadClass
> > has the execution of its CINT part done immediately (and not
protected
> > for multi-thread).
> >
> > Both the calls are asking CINT to load a file and in this case,
> > __sometimes__ the loading of RtypesCint.h is happening __while__
loading
> > the libraries thus over-writing (randomly) part of one of the
loading.
> >
> > The problem did indeed worsen since ROOT 3.03/07 with the
introduction
> > of the first ProcessLine.
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:16 MET