Re: Jon Skeet's thread pooling sample

From: David Levine (noSpamdlevineNNTP2_at_wi.rr.com)
Date: 10/18/04 

Date: Sun, 17 Oct 2004 19:16:05 -0500

<snip>
> Unfortunately, that doesn't work due to .NET only allowing you to set
> the thread name once :(

Oops, right - darn it. I really do wonder what the justification was for
that decision - I can't think of a good reason why the name of a thread has
set-once semantics.

<snip>
>
> Unfortunately it's not that simple, for the reasons you state later.
>
> Given that all of this is entirely different to the way .NET treats
> event handlers the rest of the time, I think I'll go for something like
> this:
>
> 1) Implement the idea of cancelling further processing of the event - I
> like that.
>
> 2) Use the normal .NET semantics of "whatever was subscribed when the
> event is fired, use that" - don't try to react to changes during the
> event.
>
> 3) Use the normal .NET semantics of an exception stopping further
> processing.
>
> 4) Add some sort of exception logging for this and the other events.
>

All that sounds reasonable to me. After I sent out my last msg I started
thinking about the code snippet I had sent and realized there were a number
of problems with it...it's the sort of code you really want to think about
and not just whip up in 10 minutes.

> Yup. That's where things get tricky. I think it *could* be implemented
> using a very clever linked list to track the whole invocation list
> (never actually combining any delegates) but I don't think it's worth
> it, to be honest.

Agreed. If that ever became a requirement then the entire worker item/thread
mechanism may need to be reworked.

>
>> > But then, do I definitely want the ThreadPool to stop if a non-
>> > CLSCompliant exception is thrown? ThreadAbortException won't be
>> > swallowed, because it *can't* be swallowed. Then again, I see that I
>> > don't have an extra catch{} block in the main worker loop, so I ought
>> > to at least be consistent.

I remembered something that I missed the first time around - you can catch
the ThreadAbortException and reset it yourself (assuming you have sufficient
security).

<snip>
> Right. Presumably that means the code should be compiled with TRACE and
> DEBUG defined, right? Otherwise those calls are removed entirely, I
> believe. That's the other thing about libraries - having a debug
> version and a separate release version is often a pain, IMO :(
>

Good point. You can always define those constants even for a release build
if necessary.

> <snip>
>
> [Exception handler getting parameters]
>> > That's a nice idea. The disadvantage is that the parameters couldn't be
>> > garbage collected until after a job completed or failed. I don't know
>> > how significant a disadvantage that would be.
>>
>> I don't think that matters much because if an exception occurs it is
>> already
>> going down a sub-optimal code path anyway.
>
> But the problem is, you've got to keep the parameters around *whether
> or not* an exception is thrown, just in case an exception is thrown.

Refactoring the code might provide a way to avoid that, but it probably
isn't worth the effort. I usually don't worry too much about the performance
and memory penalties associated with exceptions because once you accept that
after you have an exception the performance in that code path is horrible,
then the extra bit of horribleness isn't all that much worse. Unless you
have LOTS of exceptions occurring at a high rate, in which case the
application probably is doomed anyway.

I think it requires care in laying it all out, but I wouldn't let the
possible memory pressure stop me from providing some potentially extremely
useful functionality.

Another possibility to consider is to change the arguments in the work item
from an array to a single object. The caller can still provide an object
that is an array, but it wouldn't force everyone to allocate an array when a
single object will suffice.

>
> I think letting the exception propagate is probably the way forward -
> it's a shame I can't detect whether or not AppDomain.UnhandledException
> has a handler attached already...

You could always add your own handler onto the chain, but I've not convinced
myself that this would be all that useful.

>
> Received - I'll have a look. I think the problem is that there's a
> potential race condition just about whatever you do. I think I'll try
> to fix it so it creates threads in fewer cases, but when in doubt it
> should create one. I suspect the logic is "when I add the item to the
> queue, was it empty before? If so, start a thread if none are running.
> Otherwise, start a thread if fewer than the maximum number of threads
> are running."

That is exactly the type of logic that it would take, and while there are
ways to eliminate the race it involves a rather complicated handshaking
using two or more events - it isn't worth it in this case. I think a simpler
mechanism will suffice.

> <snip>
>
> I don't think I want to set it before the worker item callback itself -
> I want to set it before the "before work item" event is raised, so that
> if that decides to change the priority, it can. I'll set it to the
> default again after the "after work item" event is raised. Sound
> reasonable?

Yes that ought to do it. It needs to be set before the 1st callback occurs
and reset after the last callback has completed.

Cheers,
Dave

Relevant Pages

  • Re: Analyzing this Progression
    ... 7ths of 7th chords resolve downward. ... No, it's not an exception. ... the lower member rises or falls. ...
    (rec.music.theory)
  • Re: When is a function not a function?
    ... a DOM element and Array or a value with falseness. ... assertion that the test betrays poor design. ... assume the worst case (that the exception will be thrown), ...
    (comp.lang.javascript)
  • Re: A C++ Whishlist
    ... Java is annoying enough with its exceptions to the operator overloading ... What's the point in "catching" an exception for a statement where you ... "Je ein Stueckchen Kreppsohle an die Fuesse eines Hamsters kleben. ...
    (comp.lang.cpp)
  • Re: bizarre malloc problem
    ... > Snis Pilbor wrote: ... Debugging indicates the exception is indeed ... > the heap. ...
    (comp.lang.c)
  • Re: How to catch exceptions?
    ... I do get erros which are now caught by CallBack, ... if (gWaitingForSendToComplete) ... catch (Exception ex) ... 63353618957615 Waiting for complete New Subject: TEST EMAIL NC 11:29:17 ...
    (microsoft.public.dotnet.framework.aspnet)