yes, I did. This approach is OK for online histogramming when it is
possible to put all the variavles for histogramming into a relatively
small array, however
it is not so well suited for event display purposes: in this case one
has to have almost all the memory shared between main and display
processes.
It would be much better to run display process as a thread (the same
holds for the dialog - ideally dialog should be asynchronous!),
several years ago I even implemented this under MS/DOS.
On UNIX however there is a caveat. Not all the flavours of UNIX support
vfork, so whatever you do for example on IRIX, the job swap space
immediately doubles after you vfork a subprocess. May be it is
not a problem - but it certainly requires some study.
> It should be since as I was constantly telling on this list ANY
> operation with Widget/Windows is an INTERACTIVE one and NEEDS some
> sort of even loop.
> Leaving
>
> theApp.Run(kTRUE);
>
> one does leave the ROOT event loop so NO interactive operation is
> allowed at this point.
>
It was just a matter of my ignorance and the lack of documentation:
based on the documentation one can only guess what TCanvas::Close
and TCanvas::Delete really do and what is the differentce between
TCanvas::Delete and operator delete. As Rene pointed out there is a
way to make the code reentrant...
...this is from your second mail:
>
> By the way did you try your example under Windows. Under Windows
> the event loop is impleneted as a separated thread of the main
> application and leaving theApp.Run(kTRUE); doesn mean closing that
> thread (anyway I hopt i could be fixed).
>
Unfortunately CDF doesn't have any NT-running platform...
I agree, having a thread seems to me to be a right thing.
Pasha.