RE: [DotGNU]Safely implementing Thread.Abort

[Thong (Tum) Nguyen]

> -----Original Message-----
> From: Russell Stuart [mailto:address@hidden
> Sent: Thursday, 20 May 2004 2:18 p.m.
> To: Thong (Tum) Nguyen
> Cc: DotGnu-Develop
> Subject: Re: [DotGNU]Safely implementing Thread.Abort
> 
> On Thu, 2004-05-20 at 07:36, Rhys Weatherley wrote:
> > 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).
> 
> This relies on knowing whether any code calls
> Thread.Abort().  There are two issues with that.  First
> of all, how are you going to know?  Scan every assembly
> referenced when you first start up?  Some of these
> assemblies might use Thread.Abort(), and yet it may
> never be called.
> 
> Secondly, what about programs that do a
> System.Reflection.Assembly.Load? You might discover
> the loaded assembly might calls Thread.Abort() after
> you have generated some code.  A variation on the theme
> is Remoting.  A remote procedure may call Thread.Abort().
> I see how you could know that.
> 
> On Thu, 2004-05-20 at 08:47, Rhys Weatherley wrote:
> > For now, implement the check on backwards jump as-is.
> 
> This will always work, but you have generate equivalent
> code for the JIT.  Will you be able to bring yourself
> to do that?  It won't be just an instruction or two.
> The "tst" op-code will overwrite the CPU's condition
> flags, which will have to be restored if you are
> doing a conditional backward jump.  In any decently
> optimised code most of them are conditional.
> 
> On Thu, 2004-05-20 at 08:18, Rhys Weatherley wrote:
> > How exactly are you going to do that?  The CVM instruction
> > pointer is probably going to be in a register (esi on x86).
> > You cannot guarantee that the CVM instruction pointer is in
> > "thread->pc" when an abort occurs.
> 
> This is true.  In fact even in a Unix Signal you will have
> no idea of the "true" value of thread->pc - because you don't
> in general know what register it is in.
> 

I pc register is specified explicitly.  Both windows and some unixes do
provide a CONTEXT/signalcontext that will give you the values of these
registers at the time of interrupt.  Is it not possible to simply restore
the appropriate registers and then jump to the right place in the new
abort-aware code?


Regards,

^Tum