Re: Run code part (like threadproc) in separate process
- From: Tommy <badaddress@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 13 Nov 2008 03:18:34 -0500
Ami wrote:
Hi All,
I have a multithreaded program where it runs threadProc and creates
some process level session objects. The problem is that if session
object becomes unstable due to some error, program need to be
restarted as it cannot recreate the new working session and stops
other threads as session object also gets corrupt their too.
I want to shift this thread proc code into separate processes so that
if some problem occurs, i destroy the process and retstart new process
with new session.
Could any one help me to find a way to do it?
I looked a lot in MSDN and google but cannot find anything which gives
me idea to create a process which can run insted of thread.
Thanks for any help in advacne..
One design issue typically here when making this decision (which incidentally, it a something we went thru as well) is how the threads are related with shared resources.
So the independence of your threads in this solution. For us, we are somewhat lucky because its an RPC client/server system and threaded RPC clients all have a single source backend RPC server to work with. Each client is independent.
But here is the basic idea for a solution using our model:
Basic Description:
We have X number of similar dlls (WCOxxx.DLL) that, each modeled the same way which are loaded by a single EXE (WCONLINE). As each dll is loaded, its thread is started, registered itself with the EXE for GUI display and control functions, etc. So you have:
wcONLINE.EXE
wcOThread1.DLL
wcOThread2.DLL
wcOThread3.DLL
wcOThread4.DLL
..
wcOThreadX.DLL
The Basic Problem:
If one dll fails, it fails the process. Of course, better exception handling is one way to help control this, but overall, if its critical, the failed dll requires the process to stop.
One Basic Solution:
- As you considered, separate the DLLs (Threads) into their own Process.
Basically, we created a lite version of WCONLINE.EXE called WCOLOADER.EXE with command line options to allow us to run each DLL as a separate process.
wcoloader /dll:wcothread1.dll
wcoloader /dll:wcothread2.dll
This solved the basic problem. It also helped us provide a way to the loader to start the each DLL as individual NT services. If you noticed, this design is how Windows doe many thing of its services using a single process loader.
So using this approach, play around with a stripped down version of your PROCESS exe or if you are not using DLLS and your threads are all in the same code, then make it optional to start a specific thread via the command line:
myprocess.exe /thread:ThisThread
myprocess.exe /thread:ThatThread
and so on.
The irony here with your post is that I've been working on the last few hours,, looking at wcoloader to help address new SMP considerations and scalability issues. Like adding IOCP to wcoLOADER, etc.
But for your design issue, the simple approach to explore is the approach I described above. If you already have your threads written in the main process code , then you can use some switch or option to just start a particular thread over another. I think this approach is a simple way to explore the problem and play around - just like we did. :-) Also, you would be killing a few birds with one stone. :-)
Of course, as stated first, much depends on how these threads are related to each other. If independent and self contained, then it should be a simple solution. If not, then these like shared memory maps may come into play.
Hope this helps.
--
.
- Follow-Ups:
- References:
- Prev by Date: Re: _SECURE_SCL should be off
- Next by Date: Re: Run code part (like threadproc) in separate process
- Previous by thread: Re: Run code part (like threadproc) in separate process
- Next by thread: Re: Run code part (like threadproc) in separate process
- Index(es):
Relevant Pages
|
Loading
