Thread: Thread.Abort() and SmtpMail does not work thougether?

[Guest]

I am making a windows-service in C#.NET 1.1 (that altso should be possible to
run as an application for testing).

The service shall do some work and sleep between each time the work is done
(the sleep time is set in app.config).
Using Thread.Sleep for pausing the application between each time the work is
done.

To be able to close the application/service anytime while in sleep its
running in its own thread.
Waiting with Abort() to Thread.ThreadState != ThreadState.Running.

This works fine until I use SmtpMail.Send in the thread.
If i do Thread.Abort() on the thread while it is sending a mail the
application stops responding but does not close.
The prosess must be aborted the hard way.
Thread.Join() does not help.

Any suggestion?

 

[Willy Denoyette [MVP]]

|I am making a windows-service in C#.NET 1.1 (that altso should be possible
to
| run as an application for testing).
|
| The service shall do some work and sleep between each time the work is
done
| (the sleep time is set in app.config).
| Using Thread.Sleep for pausing the application between each time the work
is
| done.
|
| To be able to close the application/service anytime while in sleep its
| running in its own thread.
| Waiting with Abort() to Thread.ThreadState != ThreadState.Running.
|
| This works fine until I use SmtpMail.Send in the thread.
| If i do Thread.Abort() on the thread while it is sending a mail the
| application stops responding but does not close.
| The prosess must be aborted the hard way.
| Thread.Join() does not help.
|
| Any suggestion?
|

You are missing the point of windows services here. Services are meant to
run in the background and stay running until system shutdown or until they
are requested to stop (which is exactly what happens at system shudown),
that means you should "stop" the service using the SCM provided protocol
(stop, pause, start...), and handle the stop event in your OnStop
eventhandler.
Using Thread.Abort does not stop the application (unless it's the main
thread), it 'tries' to abort a thread, if that thread happens to be blocked
in unmanaged code, the Abort will not be honoured. If you need to stop an
application cold, you'll have to call Environment.Exit, but again Services
aren't regular applications, use the protocols provided to control them.

Willy.

 

[Guest]

DAMN!!

I had a long answer that got lost when posting - because the service wonted
me to log in again!
But for reading the posts I dont have to log in again :-(


So for short:

I am using OnStop when running as a service and a stop button when running
as a application (for test).

I wont the service to wait until the child thread is in sleep mode and not
running before exiting.
And it must be possible to stop it while in sleep mode (that can be several
minutes).

The same goes when running as an application.

- WS

 

[Willy Denoyette [MVP]]

Don't sleep for that long, sleep repeadedly for short periods and check for
an event or a shared flag, but don't use Thread.Abort.

Here is a sample...
//calling thread (or OnStop).
// shared variable
bool continue= true;
....
// order service thread to stop
continue = false;

// your service thread
....
while(true){
// Sleep at most 10 minutes or until continue == false
// check the continue flag every 5 seconds
while((continue) || cnt < 120)
Thread.Sleep(5000);
if(!continue)
return; // exit from thread procedure
else
// do what you have to do
....
}

Willy.


|
| DAMN!!
|
| I had a long answer that got lost when posting - because the service
wonted
| me to log in again!
| But for reading the posts I dont have to log in again :-(
|
|
| So for short:
|
| I am using OnStop when running as a service and a stop button when running
| as a application (for test).
|
| I wont the service to wait until the child thread is in sleep mode and not
| running before exiting.
| And it must be possible to stop it while in sleep mode (that can be
several
| minutes).
|
| The same goes when running as an application.
|
| - WS
|
|
| >
| > You are missing the point of windows services here. Services are meant
to
| > run in the background and stay running until system shutdown or until
they
| > are requested to stop (which is exactly what happens at system shudown),
| > that means you should "stop" the service using the SCM provided protocol
| > (stop, pause, start...), and handle the stop event in your OnStop
| > eventhandler.
| > Using Thread.Abort does not stop the application (unless it's the main
| > thread), it 'tries' to abort a thread, if that thread happens to be
blocked
| > in unmanaged code, the Abort will not be honoured. If you need to stop
an
| > application cold, you'll have to call Environment.Exit, but again
Services
| > aren't regular applications, use the protocols provided to control them.
| >
|

 

[Damien]

Code samples in VB, should be easily translatable to C#

I am making a windows-service in C#.NET 1.1 (that altso should be possible to
run as an application for testing).

The service shall do some work and sleep between each time the work is done
(the sleep time is set in app.config).
Using Thread.Sleep for pausing the application between each time the work is
done.

To be able to close the application/service anytime while in sleep its
running in its own thread.
Waiting with Abort() to Thread.ThreadState != ThreadState.Running.

How about, doing this instead:

Private mAbortThread as ManualResetEvent()

Private Sub MyMagicThread
Dim Aborted as Boolean = False
While Not Aborted
......
Do your actual work here
......
Aborted = mAbortThread.WaitOne(TimePeriod,False)
End While
......
Do your thread cleanup code here
End Sub

Public Sub StartDoingThings
mAbortThread = New ManualResetEvent(False)
......
Do normal thread starting activity here
End Sub

Public Sub StopDoingThings
mAbortThread.Set()
'Do a join here if you don't want to exit the sub until thread has
terminated.
End Sub

This is quite a common techinique. It means that the Thread only gets
aborted when it is safe for it to be aborted, as opposed to the
Sledgehammer of Thread.Abort, the outcome of which you've already
discovered...

Damien