[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: A note on automatic resource management
- From: Florian Weimer <fw@...>
- Date: Sun, 23 May 2010 12:16:35 +0200
* Tobias Käs:
> Florian Weimer <fw <at> deneb.enyo.de> writes:
>>
>> [...] (This assumes that the CLR
>> does not support thread cancellation, which it probably doesn't
>> because it's difficult to get the semantics right.) [...]
>>
>
> Actually the CLR allows abortion of a managed thread by injecting an
> exception which unwinds the thread, properly executing exception
> handling clauses for cleanup. If you catch the exception and don't
> rethrow yourself, the runtime will rethrow the abort exception
> automatically once you leave the exception handling clause. To avoid
> that you can use an API call to stop the abortion process. The
> initial abort exception is not raised arbitrarily, the runtime does
> some work to only raise it in "safe" locations (whatever that may
> be, but it probably is defined in the ISO/ECMA standard).
Thanks for the clarification. So this exception is not fully
asynchronous, which is much better than the Java equivalent (which
only cleans up synchronized-style locks and generally leaves the VM in
an undefined state if there are any objects mutated by the terminated
thread and which are used after its termination).
I think this is also the way how some vendors handle thread
cancellation in C++. There is a magic exception which is rethrown
even after catch (...) blocks.
> It pretty much looks like a big hack to me, especially the "stop
> abort" API which basically is a dirty way to say 'yes I really meant
> to catch that exception, it wasn't a mistake'. But when it comes to
> practical usage I have to say it actually works very well, embedding
> applications (ASP, SQL) are using it quite often and effectively to
> abort runaway threads or 'cancel' operations which are no longer
> necessary.
I use "kill" to stop runaway processes from time to time. If you've
got an environment which encourages you to put everything into one VM,
you need some equivalent for that. But it's difficult to create a
moderately safe "kill" equivalent in an environment which is based on
shared memory concurrency.