Forms: Process vs Thread

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

I have an application that consists of a main menu and
multiple forms launched from that main menu. Currently,
all the forms are launched as separate threads with their
own Windows message loop (using Application.Run). This
allows the forms to communicate with each other and with
the main menu (for statusing). The forms can also access
common data in static variables. Another reason for
having threads is that they launch faster and are more
lightweight than a process. This works fine except
occasionally, one of the forms goes busy and gets locked
up and then when the user clicks on the X to close the
form, Windows pops up the standard "The application is
not responding. Do you want to close it". When the user
does so, the entire application closes, not just that
form. I am trying to find out if I can intercept that
application kill and direct it to a form of mine that
would let the user kill the one thread in the application
that is causing problems. If I had to I guess I could
launch my forms as processes, but then I would have to
provide a mechanism for them to communicate with each
other and with the common data.
Thanks.
 
Does it make any difference if you set that thread to background?
(Not for your main form - the one you call main menu, but for the threads
you start for the other forms).

Jerry
 
I tried setting the threads to background and that did
not help. I think the problem is that the child form
gets busy and does not process Windows messages. When
Windows sends the Close message, it doesn't get
processed, Windows notices that the form didn't go away,
and then issues a Kill on the Process. I am going to see
if I can have each child form launch a thread that peeks
at its message loop and intercepts the Close message.
Mark
 
Mark said:
I tried setting the threads to background and that did
not help. I think the problem is that the child form
gets busy and does not process Windows messages. When
Windows sends the Close message, it doesn't get
processed, Windows notices that the form didn't go away,
and then issues a Kill on the Process. I am going to see
if I can have each child form launch a thread that peeks
at its message loop and intercepts the Close message.
Mark
Click to expand...

Don't do it this way, have a UI threads and worker threads, OnClose() of a
UI thread it would close the worker thread.
The other way if headed for chaos.
 
-----Original Message-----



Don't do it this way, have a UI threads and worker threads, OnClose() of a
UI thread it would close the worker thread.
The other way if headed for chaos.


.
Click to expand...
I'm not sure that I understand you.
I have multiple UI threads in one process.
Even if one of my UI threads creates a worker thread
and that closing the UI thread closed the worker thread,
I still have a problem if one of the UI threads is
blocked and Windows issues a kill on the process.
 
Hi Mark,



I haven't found a way to accomplish that. If you can afford it (runtime
resources) then I would suggest to spam (child) processes. The communication
can be done via .net remoting and should be quite transparent. It's slower
than in your current scenario, but if there aren't too many calls going on,
it's not that bad.



You probably won't succeed having an other thread peeking messages from your
gui thread since peekmessage and getmessage work implicitly for the thread
they're called from (as far as I know there is no way to change that).



How ever, as a work around you can have something like a watch dog which
monitors whether your gui threads are still processing messages or not. If
it figures that messages aren't processed anymore, it simply kills the
thread. How ever, this might result in resource leaks.



If you find a better solution please let us know.



regards



Christian
 
Back
Top