Hi,
Assume I have Main function that looks like this:
static void Main(string[] args)
{
Action h1 = new Action(0);
Thread hilo1 = new Thread( new ThreadStart( h1.go ));
hilo1.Start();
}
What will happen if the thread I created hasn't finished when the main thread
exits Main()?
Is it advisable to call hilo1.Join() before exiting Main() ?
How's this thing handled usually? O:-)
Thanks! 10 1886
If the thread is a background thread, it will be terminated with the
application.
If it's not a background thread, the process will live until the thread
returns.
To indicate it as a background thread, set the property IsBackground to true
on the thread object.
--
Patrik Löwendahl [C# MVP] www.cshrp.net - "Elegant code by witty programmers"
"Fernando Rodríguez" <fe*******************@fernando-rodriguez.com> wrote in
message news:8d********************************@4ax.com... Hi,
Assume I have Main function that looks like this:
static void Main(string[] args) {
Action h1 = new Action(0);
Thread hilo1 = new Thread( new ThreadStart( h1.go )); hilo1.Start(); }
What will happen if the thread I created hasn't finished when the main thread exits Main()?
Is it advisable to call hilo1.Join() before exiting Main() ?
How's this thing handled usually? O:-)
Thanks!
"Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in
message news:eW**************@tk2msftngp13.phx.gbl... If the thread is a background thread, it will be terminated with the application.
If it's not a background thread, the process will live until the thread returns.
To indicate it as a background thread, set the property IsBackground to true on the thread object.
I was about to respond that IsBackground can only be set before the thread
is started, but you're absolutely right, it's a fully mutable property.
Which leads me to the following question: is the following program
guaranteed to terminate?
using System;
using System.Threading;
class Background {
public static void Main() {
Background b = new Background();
Thread t = new Thread(new ThreadStart(b.DoSleep));
t.Start();
}
public void DoSleep() {
Thread.Sleep(5000);
Thread.CurrentThread.IsBackground = true;
Thread.CurrentThread.IsBackground = false;
while (true) { }
}
}
It does terminate, for me, as a console program built with .NET 1.1, but I
don't see any guarantee in the documentation that, at the moment a thread is
set to background, the state of all threads will be checked, and termination
will occur if no foreground threads remain.
I admit that this is largely of academic interest, since I can't picture it
ever being necessary to depend upon this behavior rather than doing
something more straightforward.
Theoreticly,
The framwork calls Abort on all background threads when there's no more
foreground threads. So theoreticly it would always terminate since there's
no more foreground threads when you mark that one as a background thread.
--
Patrik Löwendahl [C# MVP] www.cshrp.net - "Elegant code by witty programmers"
"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... "Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in message news:eW**************@tk2msftngp13.phx.gbl... If the thread is a background thread, it will be terminated with the application.
If it's not a background thread, the process will live until the thread returns.
To indicate it as a background thread, set the property IsBackground to true on the thread object.
I was about to respond that IsBackground can only be set before the thread is started, but you're absolutely right, it's a fully mutable property. Which leads me to the following question: is the following program guaranteed to terminate?
using System; using System.Threading;
class Background { public static void Main() { Background b = new Background(); Thread t = new Thread(new ThreadStart(b.DoSleep)); t.Start(); }
public void DoSleep() { Thread.Sleep(5000); Thread.CurrentThread.IsBackground = true; Thread.CurrentThread.IsBackground = false; while (true) { } }
}
It does terminate, for me, as a console program built with .NET 1.1, but I don't see any guarantee in the documentation that, at the moment a thread is set to background, the state of all threads will be checked, and termination will occur if no foreground threads remain.
I admit that this is largely of academic interest, since I can't picture it ever being necessary to depend upon this behavior rather than doing something more straightforward.
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly, The framwork calls Abort on all background threads when there's no more foreground threads.
Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
My bad, the abort isn't called in a managed sense. Sorry for that..
--
Patrik Löwendahl [C# MVP] www.cshrp.net - "Elegant code by witty programmers"
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly,
The framwork calls Abort on all background threads when there's no more foreground threads.
Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: My bad, the abort isn't called in a managed sense. Sorry for that..
No problem - just glad I hadn't missed something :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly,
The framwork calls Abort on all background threads when there's no more foreground threads.
I was going by the online docs for Thread.IsBackground: http://msdn.microsoft.com/library/de...roundTopic.asp
A thread is either a background thread
or a foreground thread. Background
threads are identical to foreground threads,
except that background threads do not prevent
a process from terminating. Once all foreground
threads belonging to a process have terminated,
the common language runtime ends the process
by invoking Abort on any background threads that
are still alive
Taken literally, it doesn't apply, since no threads were terminated.
Perhaps there's a more precise statement elsewhere.
Really? Is this documented somewhere? I thought the process just terminated when there were no more foreground threads. That's quite different from Abort being called, as Abort allows for some clean-up.
It does say that Abort is called; I haven't tried it.
It's not effectivly doing a managed abort on the thread since no ThreadAbort
(nor ThreadInterrupt) Exception is throwed so I would imgine that they're
talking in an unmanaged sense.
--
Patrik Löwendahl [C# MVP] www.cshrp.net - "Elegant code by witty programmers"
"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP09.phx.gbl... "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly,
The framwork calls Abort on all background threads when there's no more foreground threads.
I was going by the online docs for Thread.IsBackground:
http://msdn.microsoft.com/library/de...roundTopic.asp
A thread is either a background thread or a foreground thread. Background threads are identical to foreground threads, except that background threads do not prevent a process from terminating. Once all foreground threads belonging to a process have terminated, the common language runtime ends the process by invoking Abort on any background threads that are still alive
Taken literally, it doesn't apply, since no threads were terminated. Perhaps there's a more precise statement elsewhere.
Really? Is this documented somewhere? I thought the process just terminated when there were no more foreground threads. That's quite different from Abort being called, as Abort allows for some clean-up.
It does say that Abort is called; I haven't tried it.
"Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in
message news:uY***************@TK2MSFTNGP11.phx.gbl... -- Patrik Löwendahl [C# MVP] www.cshrp.net - "Elegant code by witty programmers"
"Mike Schilling" <ms*************@hotmail.com> wrote in message news:eg**************@TK2MSFTNGP09.phx.gbl... "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om... Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly,
The framwork calls Abort on all background threads when there's no more foreground threads. I was going by the online docs for Thread.IsBackground:
http://msdn.microsoft.com/library/de...roundTopic.asp
A thread is either a background thread or a foreground thread. Background threads are identical to foreground threads, except that background threads do not prevent a process from terminating. Once all foreground threads belonging to a process have terminated, the common language runtime ends the process by invoking Abort on any background threads that are still alive
Taken literally, it doesn't apply, since no threads were terminated. Perhaps there's a more precise statement elsewhere.
Really? Is this documented somewhere? I thought the process just terminated when there were no more foreground threads. That's quite different from Abort being called, as Abort allows for some clean-up.
It does say that Abort is called; I haven't tried it.
It's not effectivly doing a managed abort on the thread since no ThreadAbort (nor ThreadInterrupt) Exception is throwed so I would imgine that they're talking in an unmanaged sense.
Iin "invoking Abort on any background threads" in the online docs, "Abort"
is a hyperlink to the Thread.Abort method. I don't see that behavior, but
it's certainly what the documentation says.
Actually, it's fairly well documented that it does NOT call abort, or
perform any other cleanup, when the process is about to be terminated. A
simple console app can demonstrate that...start a background thread with a
finally block that prints something out to the console/trace/whatever, and
then exit the main thread...you should find that the finally block never
executes.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote: Theoreticly,
The framwork calls Abort on all background threads when there's no more foreground threads.
Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Matthew Bell |
last post by:
Hi,
I've got a question about whether there are any issues with directly
calling attributes and/or methods of a threaded class instance. I
wonder if someone could give me some advice on this.
...
|
by: Deepak Sarda |
last post by:
Hello everyone.
I have run into something which I believe is a bug or a shortcoming of
the threading.Thread module.
My program spawns 15 threads. For this I've creating a new class with...
|
by: Steven Bethard |
last post by:
I'm playing around with some threading stuff right now, and I'm having a
little trouble calling a function from one thread that affects another.
Here's my setup:
py> import os, threading, time...
|
by: Gilles Leblanc |
last post by:
Hi I have started a small project with PyOpenGL. I am wondering what
are the options for a GUI. So far I checked PyUI but it has some
problems with 3d rendering outside the Windows platform.
I...
|
by: Bryan |
last post by:
I have a multi-threaded C# console application that uses WMI
(System.Management namespace) to make RPC calls to several servers (600+ )
and returns ScheduledJobs. The section of my code that...
|
by: Bryan |
last post by:
I have a multi-threaded C# console application that uses WMI
(System.Management namespace) to make RPC calls to several servers (600+ )
and returns ScheduledJobs. The section of my code that...
|
by: fred |
last post by:
I use a Synclock in a secondary thread and also stop the thread using the
abort method.
If the abort occurs while the thread is in the Synclock will the SyncLock
always be released before the...
|
by: Joe |
last post by:
Does anyone know the difference, in practical terms, between
Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??
The MSDN says that with Join, standard COM and SendMessage pumping...
|
by: dshereck |
last post by:
Hello,
I implemented a simple c++ thread wrapper; it works in Linux, but fails in
BSD.
Here is the code. The idea is that an other class will inherit and implement the virtual methods Setup...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |