Seeking Advice for Starting a Windows Service

[Joseph Geretz]

I have a Service which runs OK, but I'm abviously not starting it properly.
In my OnStart event I commence a long running process which polls a database
table and performs various processing. Since this polling loop is entered
synchronously from OnStart, basically the OnStart event doesn't terminate
for the life of the program. This doesn't give the SCM the correct feedback
that the service has started properly. Consequently, the SCM throws an error
dialog and the service is marked as 'Starting', even though the service is
in fact running properly. I'd like to correct this.

I guess the best practice approach would be to perform initialization
synchronously just to make sure that all necessary resources are obtained,
and then launch into the main service routine asynchronously so that the
OnStart event can terminate in a timely manner. But I'm not sure how to do
this.

Also, any advice on how the service can execute at a low background priority
will be very much appreciated.

Thanks for your advice!

- Joseph Geretz -

 

[Tom Shelton]

I have a Service which runs OK, but I'm abviously not starting it properly.
In my OnStart event I commence a long running process which polls a database
table and performs various processing. Since this polling loop is entered
synchronously from OnStart, basically the OnStart event doesn't terminate
for the life of the program. This doesn't give the SCM the correct feedback
that the service has started properly. Consequently, the SCM throws an error
dialog and the service is marked as 'Starting', even though the service is
in fact running properly. I'd like to correct this.

I guess the best practice approach would be to perform initialization
synchronously just to make sure that all necessary resources are obtained,
and then launch into the main service routine asynchronously so that the
OnStart event can terminate in a timely manner. But I'm not sure how to do
this.

Also, any advice on how the service can execute at a low background priority
will be very much appreciated.

Thanks for your advice!

- Joseph Geretz -

Just create a thread in the onstart routine, and perform your work in
the thread method... You can also set that threads priority.
Something like:

// do resource aquisition
// create your thread, and set the priority, and start it up
Thread worker = new Thread (new ThreadStart (WorkerMethod));
worker.Priority = ThreadPriority.BelowNormal; // Or Lowest if you like
worker.Start();

Then you just do your actual work in the WorkerMethod. You can signal
the thread to end from the OnStop method, etc.

HTH

 

[Michael C]

I have a Service which runs OK, but I'm abviously not starting it properly.
In my OnStart event I commence a long running process which polls a
database
table and performs various processing. Since this polling loop is entered
synchronously from OnStart, basically the OnStart event doesn't terminate
for the life of the program. This doesn't give the SCM the correct
feedback
that the service has started properly. Consequently, the SCM throws an
error
dialog and the service is marked as 'Starting', even though the service is
in fact running properly. I'd like to correct this.

I guess the best practice approach would be to perform initialization
synchronously just to make sure that all necessary resources are obtained,
and then launch into the main service routine asynchronously so that the
OnStart event can terminate in a timely manner. But I'm not sure how to do
this.

Also, any advice on how the service can execute at a low background
priority will be very much appreciated.

Thanks for your advice!

Just start a thread in OnStart and set it's priority to be low

Thread thread = new Thread(new ThreadStart(DoStuff));

thread.Priority = ThreadPriority.Lowest;

thread.Start();

 

[Joseph Geretz]

OK, thanks guys - very helpful.

But how do I cancel a thread? I guess I can't just kill the operation. Is
cancelling a thread simply setting a flag on the thread and my code needs to
monitor that flag to see when it is set in order to terminate? (This seems
to be the way it would work for a BackgroundWorker?) Is there any reason to
prefer a Thread over a BackgroundWorker object or vice versa? I guess the
two approaches would be similar? (Please forgive the basic questions. As an
ex-VB6 devleoper, I haven't had much exposure to threads up to this point.)

Thanks for your advice.

- Joe Geretz -

 

[oscar.acostamontesde]

OK, thanks guys - very helpful.

But how do I cancel a thread? I guess I can't just kill the operation. Is
cancelling a thread simply setting a flag on the thread and my code needs to
monitor that flag to see when it is set in order to terminate? (This seems
to be the way it would work for a BackgroundWorker?) Is there any reason to
prefer a Thread over a BackgroundWorker object or vice versa? I guess the
two approaches would be similar? (Please forgive the basic questions. As an
ex-VB6 devleoper, I haven't had much exposure to threads up to this point.)

Thanks for your advice.

- Joe Geretz -

you can use a flag
bool run = true

while(run){
// Do some work
// Check condition
run = false;
}

 

[Joseph Geretz]

Hi Oscar,

you can use a flag
bool run = true

while(run){
// Do some work
// Check condition
run = false;
}

So what you're saying is that when the method which is running on the thread
terminates, the thread itself is terminated automatically?

Thanks for your help,

- Joseph Geretz -

 

[Tom Shelton]

Hi Oscar,



So what you're saying is that when the method which is running on the thread
terminates, the thread itself is terminated automatically?

Thanks for your help,

- Joseph Geretz -

Yes, when a thread method exits - so does the thread. Be a little
careful using a flag like this though to end the thread - especially
if it is going to be set from outside the thread... While on x86
processors, reads and writes of this type are guarenteed to be atomic
- you may still get unexpected results. The reason is that sometime
the compiler will optimize the code to read from a register instead of
the actual memory value. When this happens in a threaded environment,
you may set the value to false - but the thread will never see it
happen... You have two choices to fix this - one use a lock or
declare the bool as volatile (which would be my prefered method in
this case . By declaring it volatile, you tell the compiler that
this value maybe changed from an outside source, and to always fetch
it from memory.

 

[sloan]

Look here:
http://blogs.msdn.com/bclteam/archive/2005/03/15/396428.aspx

I would append his article by saying you want to have a

when you start you "actual code" I would kill off the timerDelegate...
after you job run, reinstantiate the timerDelegate.