Let's say some one makes the argument that instead of multi threading an
application, they say it's better just to make multiple applications. The
app does the same thing for different modules. The modules are conceptually
the same. They contain mostly data but some processing to get data. The
app knows nothing about how they get the data. Just that they return data
in a starndard format. The argument is based on 12 apps vs. 1 multi
threaded app. 1 app can crash and leave the others alone. Whereas a multi
threaded app can have one thread crash and bring down the whole thing.
Consider the multi threaded app uses an interface with 12 classes to
encapsulate variability. Most work is done in one main class on the other
side of the interface and makes use of these 12 classes. I say
encapsulating the variability and using the interface is best. As for one
thread bringing down the whole app, there are two places to catch this.
First, if one thread has a problem, it's own error catching should take care
of it. Second, if the problem falls through the child thread, the main
thread can catch it. Of course, if there is a problem in the main thread,
all 12 child threads have an issue since the main thread must run. The
whole thing may stop at this point.
Contrast that with the 12 different applications. If one of the apps have a
problem in the main processing area because it received bad data from its
child class, the other 11 apps keep on going.
My question is, without regards to code maintenance, which clearly the
interface design wins hands down, or other topics, is the 12 app model
better than the multi threaded app that basically puts each app on its own
thread in the same process?
Thanks,
Brett
