Prev: Handle Leak driving me mad (seems to have something to do with Threading)
Next: about ThreadState
From: Tony Johansson on 16 Jun 2010 16:11
Hello!

Here is some docs about what is said about it.
Notifies a host that execution is about to enter a region of code in which
the effects of a thread abort or unhandled exception might jeopardize other
tasks in the application domain.

Used to notify the host that code to be executed cannot be aborted safely.
Aborting a thread between a BeginCriticalRegion and EndCriticalRegion might
leave an AppDomain in an unsafe state.

Now to my question as you know this BeginCriticalRegion/EndCriticalRegion
doesn't prevent an abort to occur between these two regions. So I can't
understand what is the point in having these two regions.
In theory is just said avoid interrupt a thread when executing between these
two regions.

//Tony


From: Jeroen Mostert on 16 Jun 2010 16:30
On 2010-06-16 22:11, Tony Johansson wrote:
> Here is some docs about what is said about it.
> Notifies a host that execution is about to enter a region of code in which
> the effects of a thread abort or unhandled exception might jeopardize other
> tasks in the application domain.
>
> Used to notify the host that code to be executed cannot be aborted safely.
> Aborting a thread between a BeginCriticalRegion and EndCriticalRegion might
> leave an AppDomain in an unsafe state.
>
> Now to my question as you know this BeginCriticalRegion/EndCriticalRegion
> doesn't prevent an abort to occur between these two regions. So I can't
> understand what is the point in having these two regions.

It signals the host that it should not abort the thread if possible, but if
it does abort the thread, it should tear down the entire AppDomain (or even
all of the CLR) as it might be unstable. SQL Server CLR is a major scenario
for hosting managed code -- as you can imagine, guaranteeing stability there
is paramount, even over guaranteeing that code continues to run.

There is no way to prevent an abort because there shouldn't be. The host
must always be able to abort managed code, that's why it's managed. In
practice, this can only be guaranteed if the hosted code is tightly
controlled, in particular, if it doesn't call any unmanaged code that's not
explicitly vetted as safe by the host (because unmanaged code could always
block in an uninterruptible way). SQL Server has the concept of safe
assemblies for this.

AFAIK, these attributes have no effect under the default host (the one you
get when you run an assembly standalone) as it never aborts threads or
unloads AppDomains of its own volition; if anything sufficiently bad
happens, the entire process is simply terminated, after an attempt is made
to shut down the CLR cleanly.

--
J.
 | 
Pages: 1
Prev: Handle Leak driving me mad (seems to have something to do with Threading)
Next: about ThreadState