dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [DotGNU]Safely implementing Thread.Abort


From: Thong (Tum) Nguyen
Subject: RE: [DotGNU]Safely implementing Thread.Abort
Date: Thu, 20 May 2004 10:13:47 +1200

Rats.  I forgot that code was shared.

> -----Original Message-----
> From: Rhys Weatherley [mailto:address@hidden
> Sent: Thursday, 20 May 2004 9:36 a.m.
> To: Thong (Tum) Nguyen; address@hidden; 'Rhys Weatherley'; 'Russell
> Stuart'
> Subject: Re: [DotGNU]Safely implementing Thread.Abort
> 
> On Thursday 20 May 2004 06:58 am, Thong (Tum) Nguyen wrote:
> 
> > I think this could work...what do you guys think?
> 
> You cannot use any approach that requires the method code to be modified
> after
> it is first generated.  It isn't thread safe: what if another thread is
> executing the method while you are modifying it?  

Rats; I forgot about that.  How about making a copy of the code for the
current method and then modifying the instruction pointer for the thread to
the appropriate place in the new code?

> It isn't even thread-
> Safe
> for the thread that you are suspending: if it is suspended while the
> thread
> was in the middle of executing the NOP, then it will be in an unknown
> state
> when resumed.

I forgot to mention it but you could get around this by modifying the
instruction pointer for the thread back to the first (replaced) "NOP"
instruction if it is in the middle of the NOP markers.

> 
> Outputting abort check instructions on every backward branch is OK with
> me, as
> long as you only do it in programs that use Thread.Abort.  This can be
> detected by the loader (any assembly with a MemberRef to Thread.Abort is a
> candidate).
> 

I hope we can find a better (faster!) way because ASP.NET will use
Thread.Abort and so will AppDomain.Unload (not as serious here because abort
is called internally) :-(.

^Tum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]