doing some background work occasionally

[bonk]

I have an application that needs to perform some background work, i.e.
Logging, wich must not block the main thread. How would I basically
design such a scenario? It is obvious that I should do that on an extra
thread but I think it is a bad idea to spawn a new thread everytime a
log-message is written and let it die once the message was written. But
how do I keep a thread alive and trigger the log-messages and pass the
string to that thread? Also, should I give that thread a lower
priority? Maybe there is a best practice for this kind scenario?

[Peter Duniho]

"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...

[...] But
how do I keep a thread alive and trigger the log-messages and pass the
string to that thread? Also, should I give that thread a lower
priority? Maybe there is a best practice for this kind scenario?

I believe that the .NET worker thread pool will address what you want.

(non-existent newsgroup removed from Newsgroups: field)

[bonk]

Thank you for that tip. One questions though:

1. If an exception occurs inside a thread of a queued workitem how can
I rethrow that exception on the main thread?

Peter Duniho wrote:

"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...

[...] But
how do I keep a thread alive and trigger the log-messages and pass the
string to that thread? Also, should I give that thread a lower
priority? Maybe there is a best practice for this kind scenario?

I believe that the .NET worker thread pool will address what you want.

(non-existent newsgroup removed from Newsgroups: field)

[Marc Gravell]

I would look at a queue, accessed (for instance) via a static/singleton
pattern. Access to the queue would be sync'd. callers would
* lock
* enqueue string
* check count; if ==1 then Monitor.Pulse as have just restarted the Q
* unlock
The (single) logging thread (started in the static/singleton ctor) would
* lock
* check count
* if == 0
* Monitor.Wait
* unlock
* back to the top
* else
* dequeue
* unlock
* log
* back to the top

This way, you have a single thread that stays alive, but doesn't hammer the
CPU while the Q is empty; callers only block to enqueue, not to log.
You might also add something to allow graceful teardown of the thread
(without Thread.Abort), and I'd probably make the logging thread a
background thread anyway...

Marc

[Marc Gravell]

That sounds more like an async callback... in which case, create a delegate
to a method, and call BeginInvoke on the delagate, also providing the
callback delegate (to a method e.g. on your form). In the callback, you can
then use the Form's BeginInvoke etc to get back to the UI thread.

Marc

[Peter Duniho]

"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Thank you for that tip. One questions though:

1. If an exception occurs inside a thread of a queued workitem how can
I rethrow that exception on the main thread?

I'm not really sure what that would mean, exactly. Since the exception
doesn't occur on the main thread in that case, and the main thread would be
happily going along executing its own code, at what point would you have the
main thread get interrupted with the exception? How should the main thread
be expected to recover from the exception, given that the exception would
have nothing to do with what the main thread actually was doing?

IMHO, a much better approach would be to come up with some signaling
mechanism that your threads can use to notify the main thread of an error,
and have the main thread check that now and then. Or maybe even better,
have the worker thread, upon catching a thrown exception, use Invoke or
BeginInvoke to run a delegate on the main thread, causing the main thread to
process the error in whatever way you feel is appropriate.

Pete

[bonk]

The scenario is this: as soon as any excpetion occurs in one of the
threads the thread will be finished (there is one big try{}catch{}
inside the thread's callback. In case an exception occured the main
thread must be resonsible of handling the excpetion. This is a
requirement by design of the main application.

Or maybe even better,
have the worker thread, upon catching a thrown exception, use Invoke or
BeginInvoke to run a delegate on the main thread, causing the main thread to
process the error in whatever way you feel is appropriate.

This sounds like a good idea for my scenario. I now need to find out
how to run the delegate on the main thread an pass the exception
correctly.

Peter Duniho wrote:

"bonk" <sc************ ******@gmx.dewr ote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Thank you for that tip. One questions though:

1. If an exception occurs inside a thread of a queued workitem how can
I rethrow that exception on the main thread?

I'm not really sure what that would mean, exactly. Since the exception
doesn't occur on the main thread in that case, and the main thread would be
happily going along executing its own code, at what point would you have the
main thread get interrupted with the exception? How should the main thread
be expected to recover from the exception, given that the exception would
have nothing to do with what the main thread actually was doing?

IMHO, a much better approach would be to come up with some signaling
mechanism that your threads can use to notify the main thread of an error,
and have the main thread check that now and then. Or maybe even better,
have the worker thread, upon catching a thrown exception, use Invoke or
BeginInvoke to run a delegate on the main thread, causing the main thread to
process the error in whatever way you feel is appropriate.

Pete

[Jon Skeet [C# MVP]]

bonk wrote:

Or maybe even better,
have the worker thread, upon catching a thrown exception, use Invoke or
BeginInvoke to run a delegate on the main thread, causing the main thread to
process the error in whatever way you feel is appropriate.

This sounds like a good idea for my scenario. I now need to find out
how to run the delegate on the main thread an pass the exception
correctly.

Use Control.Invoke or Control.BeginIn voke.

See http://www.pobox.com/~skeet/csharp/t...winforms.shtml for more
details.

Jon

[Robert Ludig]

Sorry, I forgot to mention that it a console application. How would I
do it in this case? Invoke a delegate on a main thread from another
thread?
Jon Skeet [C# MVP] wrote:

bonk wrote:

Or maybe even better,
have the worker thread, upon catching a thrown exception, use Invoke or
BeginInvoke to run a delegate on the main thread, causing the main thread to
process the error in whatever way you feel is appropriate.

This sounds like a good idea for my scenario. I now need to find out
how to run the delegate on the main thread an pass the exception
correctly.

Use Control.Invoke or Control.BeginIn voke.

See http://www.pobox.com/~skeet/csharp/t...winforms.shtml for more
details.

Jon

[Chris Fulstow]

Check out the ThreadPool class:
http://msdn2.microsoft.com/en-us/lib...hreadpool.aspx

bonk wrote:

I have an application that needs to perform some background work, i.e.
Logging, wich must not block the main thread. How would I basically
design such a scenario? It is obvious that I should do that on an extra
thread but I think it is a bad idea to spawn a new thread everytime a
log-message is written and let it die once the message was written. But
how do I keep a thread alive and trigger the log-messages and pass the
string to that thread? Also, should I give that thread a lower
priority? Maybe there is a best practice for this kind scenario?