----- Original Message -----
From: "Brett Viren" <bv@bnl.gov>
To: "Valeri Fine" <fine@bnl.gov>
Cc: <roottalk@pcroot.cern.ch>
Sent: Monday, October 29, 2001 10:56 AM
Subject: Re: [ROOT] Windows Graphics/GUI - RE: More on Graphics abstraction (was Re: [ROOT] Qt ROOT)
> Valeri Fine writes:
> >
> >
> >
> > > Peter Lipa writes:
> > > >
> > > > What Valery, Thane and I are trying to tell you is that the gdklib's in
> > the
> > > > current state are not suitable for root graphics/GUI. The lib is not
> > > > threadsafe and crashes at random times.
> > >
> > > Gtk/Gdk is thread safe if all GUI related code is restriced to one
> > > thread. There are utilities (http://www.humanfactor.com/gpk/) that
> > > help non-GUI threads make safe GUI calls.
> > >
> >
> > This is very reason of the current and future ROOT Windows problem
> > with any GUI (gtk, qt, win32, mfc etc )
> > Not all "GUI related code is restricted to one thread".
> I looked at GPK at the URL above a little more closely. It works by
> wrapping all GTK+ (the underlying C code layer of Gtk--) function
> calls with GPK equivalents. The GPK versions are then thread safe
> because instead of calling the GTK function directly they queue all
> GUI requests and send them through a single pipe to the main GUI
> thread which is started by GPK and which then does the actual GTK
> call.
>
> The reason why I mention this, is that if the trouble with Bertrand's
> Windows GUI really is this treading problem, maybe he (or someone who
> wants to help him) can create a similar layer. Then all the other
> higher layers are free to use threads and access GUI classes with out
> worry. Also, as much as I don't like the practice of using
> interpreted code in compiled code, because we have
> gROOT->ProcessLine(...), implementing this layer should be fairly
> easy.
>
> And if you are right, Valeriy, about this problem being endemic to all
> GUIs, this kind of layer might be useful in ROOT at a higher level
> than just Bertrand's port. But, do I understand you correctly that
> currently on unix/X we can't run threads with the TG classes without
> worrying about this problem?
Ok this thread is going to be "Essential of the multithreaded programming".
I don't think we should go futher. One can find many nice books around.
Just a "last" comment :-(
" . . . The GPK versions are then thread safe
> because instead of calling the GTK function directly they queue all
> GUI requests and send them through a single pipe to the main GUI
> thread which is started by GPK and which then does the actual GTK
> call.
This is the way CERNLIB HIGZ was done 15 years ago and it is how the current
implementation of TVIrtualX for Windows worked. And it is the point the coming
implementation GUI for Win32 neglects (as I understood from this discussion.
I did not see that code myself). By the it jas nothing to do with the "console thread".
I think this thread can be eliminated the way Bertrand (probably) did. However
I saw no troubles with that "Console" thread.
However the dedicated GUI thread is not a magic stick. It is a tool that one may or
may not use properly ( I know it is the trivial and obvious sentence )
For the further information see http://doc.trolltech.com/3.0/threads.html and some books:
a.. Threads Primer: A Guide to Multithreaded Programming
b.. Thread Time: The Multithreaded Programming Guide
c.. Pthreads Programming: A POSIX Standard for Better Multiprocessing (O'Reilly Nutshell)
d.. Win32 Multithreaded Programming
My proposal is to close this thread. I was told people are tired of this long lasting
world -wide discussion.
Thank you for the fruitful discussion.
Best regards,
Valeri
> BTW, there are similar GUI/thread related discussions right now on the
> Gtk-- list which includes how one person does this
> pipe-to-the-gui-thread in C++. If interested see:
> http://marc.theaimsgroup.com/?l=gtkmm&m=100435666117355&w=2
>
> Regards,
> -Brett.
>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:05 MET