RE: [DotGNU]Safely implementing Thread.Abort

[Thong (Tum) Nguyen]

I think if we are going to do the thread->abortRequested (*) test (which
will be the only choice for platforms without signals support) we should do
it at the end of every function call like Russell suggested.  We don't
*really* need to abort a tight loop that contains no method calls or locks.
Those kind of loops ALMOST NEVER appear in production code and in the end,
it is still possible for Abort to never succeed on MS.NET anyway -- a thread
can always loop in a finally clause or catch ThreadAbortException and loop
there.

My vote is for checking thread->abortRequested at the end of every method
call.  The performance hit will hardly be noticeable except for the most
anal of benchmarks.  Once that's done, we can investigate speeding it up for
specific platforms like Linux and Windows using signals/win32-seh.

(*) thread->aborted is flagged if the thread has successfully thrown a
ThreadAbortException and simply indicates that the ThreadAbortException
needs to be propagated.

Regards,

^Tum

> -----Original Message-----
> From: Gopal V [mailto:address@hidden
> Sent: Thursday, 20 May 2004 8:07 p.m.
> To: Thong (Tum) Nguyen; 'Russell Stuart'
> Cc: 'DotGnu-Develop'
> Subject: RE: [DotGNU]Safely implementing Thread.Abort
> 
> Hi,
> 
> > > > 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).
> > >
> ....
> 
> Having every backward jump check for thread->aborted
> would be a initial "make it work" solution.
> 
> Not to mention that we could have an
> "--expect-no-thread-aborts"  which would
> avoid this check ? . for example, when running
> pnetmark ? ;-)
> 
> > 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?
> 
> That would be a GCC + (x86/arm/ppc) specific hack ,
> which would still not speed it up on all platforms.
> 
> But my question is whether , that much work for
> just speeding it up in 3 MAJOR platforms is
> worth the effort ;)
> 
> Gopal
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Domains  Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers