I assume you cannot have two instances of TApplication in the same executable. Is this correct?
If I am wrong, please let me know how to do two instances and ignore the rest of this post.
Why is it prohibited to have two instances? Is it due to a presumption that it is confusing or unnecessary, or is there a technical reason behind this?
You can run two executables that effectively invoke two instances of Root, simultaneously so I would have thought that it would be fairly easy to do the same within one executable.
In my opinion it would make mutithreading much simpler if this were possible. The user would have the freedom to invoke as many instances as they wanted and then manage the “bridging” between the instances. The existing “monoblock” structure of ROOT keeps apearing as an obstacle.
For example I wanted to create a thread that checks a folder structure at certain time intervals. But it was badly conflicting with the parent thread that was using the same ROOT methods for checking folders in other occasions. Eventually I gave up on using ROOT to do this job and reverted to windows method that had transparent multithreading properties.
If on the other hand I could create a separate ROOT instance for the additional thread, I presume there would be no problem whatsoever as the two instances are protected from eachother by the OS.
If everything I am saying above is wrong it would help to explain how would be the correct way of going about the example I mentioned, as this would tell me how to deal with many other similar situations.
In my opinion it would make mutithreading much simpler if this were possible.
TApplication is a very minor part of the entire setup, many more resources are shared to take advantage of the same-process nature of the multi-threading to reduce memory usage and improve coordination and coherence (gROOT object, TClass objects, TStreamerInfo objects).
If your workflow is truely independent using multiple processes is simpler et clearer. If your workflow can benefit from reduce memory usage by sharing some resources amongst the thread then multi-threading is an option but has its challenges. In case you use multi-threading, for ROOT to operate correctly you need to turn on the locking mechanism (that prevents multi-thread to access and change the same structure at the same time) by calling ROOT::EnableThreadSafety(). Even with that some calls to ROOT (and some accesses to your own data structure if they are shared) needs to have a locking mechanism in place to coordinate the shared access.
For example I wanted to create a thread that checks a folder structure at certain time intervals.
But it was badly conflicting with the parent thread that was using the same ROOT methods for checking folders in other occasions.
For more specific advise, please share the actual failing code and the description of the error.
Hi pcanal,
if I understand correctly, the single tapplication requirement is an imposed requirement, there is no technical reason why this is required. It is for the resons you listed.
But therein is exactly my issue. The Root team is making a hard assumption on how users want to use Root and what they should be doing. I understand exactly what you are saying, and in fact I had already presumed that this was the case.
However other people might have different requirements. Why is there a need to presume their behaviour? If you would like to encourage people to use a single TApplication, then you can have it as a default setting that can be switched off by a parameter.
Let me explain the problem I constantly and in many different occasions have with Root.
You are promoting a top down approach, that requires you to design the “whole” before you can start programming the “unit”. However -personally- whenever I embark to do this approach, a few months down the line I find that my original “whole” was a “part” and now I need to re-design the whole and change many different things throughout existing code, do a lot of expensive rewiring to “extend” to the new “whole”.
I personally find a different approach A LOT more effective. Split the code to many stand alone applications (really standalone) and then merge them. I design them in a way to have c++ style “universal interface” like a wrapper class with certain predefined features that make the merging really elegant. The first step in this process is to littelally glue together two such source codes as separate projects in one solution.
Now you can see how having one TApplication is an obstacle in this process. It is effectively the first big obstacle that I immediately face. All the histograms, everything I do with root, in each one of the two separate applications now has to be merged in a messy marmelade. Or make a Root thread with wrappers blah blah.
On the other hand it seems to me that if I could simply have two TApplications in one exectuable I would not need to do any of that. The beauty of this approach is that -yes-, it is not resource optimised, but once both applications are working in the same hotel, it is quite easy to start wiring them together properly at a later stage and improve resource usage, when necessary.
In the end every compiler has the option to optimise for resources or speed or nothing. This tells us that it is quite acceptable to have the freedom to implement your style of programming. If all it takes is to remove an artificial obstacle, why not do it?
PS Or you could have one TApplication with “subdirectories”. That would also be nice.
Doing the resource optimization well in a way that is properly scalable is actually a difficult task (especially couple with having to support legacy code and applications) and the solution we have ended with is doing pretty well and is still very flexible to support multiple use cases and coding pattern.
Side note, you mentioned TApplication but it is only the tip of the iceberg and that particular object is unlikely to be the one causing you some issues.
All the histograms, everything I do with root, in each one of the two separate applications now has to be merged in a messy marmelade.
With a few C++ calls and following some coding patterns. For example you take full ownership (no more automatic registration) of all the histogram by calling once at the start of you application:
TH1::AddDirectory(false);
Or you could have one TApplication with “subdirectories”. That would also be nice.
You can add subdirectories to gROOT if you want to (this might or might not be the solution to you actual issue).
In this threads there is 2 slightly distincts, one of is a overall design and architecture that will be much better discussed in person (or at least via voice) to increase the bandwith of the discussion and another which we can try to solve here is the practical/technical issue that you are encountering (i.e. please be more specific in what code is failing for you and how - note: usually it is not involve TApplication (but might of course ).
BTW. You could try (before you call any ROOT function in your application, e.g., as the very first line of your “main” routines): TApplication *a = (gApplication ? gApplication : new TApplication("a", 0, 0));
or simply: if (!gApplication) new TApplication("a", 0, 0);
).