[Mono-dev] About your changes to type initialization

[Martin Baulig]

Hi Rodrigo,

Just checked this on Windows to see how Visual Studio handles this and
you're right, it doesn't allow
the .cctor to be run twice.

However, we need to distinguish whether we're running inside the
debugger (both hard and soft), by
using a custom version of ves_icall_System_Threading_Thread_Abort().

When running _outside_ the debugger, the Thread.Abort() must block until
the .cctor has finished.

Inside the debugger, we need to allow the abort and store the
ThreadAbortException; ie. we abort immediately and mark the class
initialization as failed, so you can't use it.

VS also doesn't distinguish between implicit (from the locals window)
or explicit (explicitly requested by the user through the immediate
window) expression evaluation, it always aborts after the evaluation
timeout.

This means that your .cctors must not take any longer to complete than
the expression evaluation timeout or your entire debugging session may
go south.

So to fix this for mono, we first need to revert that revision
(hopefully getting this into 2.6.3 as well) and then, as a second step,
fix our implementation of Thread.Abort() to not abort any .cctors when
running outside the debugger.

Martin

On 03/04/2010 04:14 PM, Rodrigo Kumpera wrote:
> Hi Martin,
>
> You change in r152558 is wrong, the test you committed doesn't work on MS.
> Type constructors must no be run multiple time, even under a debugging
> session, as
> this is an assumption made by most developers that we can't break.
>
> The solution for your problem is to tag the thread as doing a .cctor
> invocation and do the abort
> right after it finishes. This is cleaner, correct and use less memory.
>
> You might ask what should happen is the .cctor blocks for way too
> long, well, the solution then
> is to interrupt the thread and accept the fact that the debugging
> session went south.
>
> I attached a reworked version of your test that has more console spew
> and shows up clearly the issue.
>
> If you could better state the problem you're trying to solve we'll be
> better able to help you fixing it.
>
> Thanks,
> Rodrigo