Re: [ROOT] GUI, threads and CINT

From: Matt Palmer (palmer@hep.phy.cam.ac.uk)
Date: Tue Jun 25 2002 - 10:39:49 MEST


Well, actually, it was a really simple app - and it turned out the fix was 
very simple too - just run the following in a thread:

void* ProcessEvents(void* arg) {
	while (true) {
		gSystem->ProcessEvents();
		gSystem->Sleep(10);
	}
	return 0;
}

Is there any reason why there can't be a thread that just processes events 
like this by default?  Or do the Xlib SMP problems prevent it?

Matt

On Thursday 13 June 2002  1:18 pm, you wrote:
>Hi Matt,
>
>  threads for such a big task might give problems. Use threads to run
>small monitors for example and run the GUI as the main program. An
>alternative is to use timers to regularly check the tasks you want to
>minitor.
>
>Cheers, Fons.
>
>On Thu, 2002-06-13 at 12:54, Matt Palmer wrote:
>> Hi,
>> I would like to know if the following is possible:
>> I want to write a GUI for some analysis code that is interpreted by CINT.
>> This analysis code typically sits in a loop, so rarely exits.  I would
>> like to present status information, logging etc in a GUI.  So, in order
>> for the GUI to remain responsive to the user, I assume I would need to run
>> the GUI in a separate thread.  Is it enough to simply create a separate
>> thread and then within that, create my main GUI object (a sub-class of
>> TGMainFrame) ?  I would then presumably make this object global so it can
>> be accessed in the analysis code.
>>
>> I was worried by the statement in the TThread documentation saying that
>> CINT will block all threads while it executes.  Is this still true?  If
>> so, would moving the analysis code to compiled (something that I'm
>> probably unable to do) code fix this?  Is there any other way of doing
>> this which I've totally missed?
>>
>> Thanks very much
>>
>> Matt



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:58 MET