[Mono-devel-list] Anyone have ideas on making ThreadAbor

[Bernie Solomon]

After I sent my email I suddenly thought of the GC and so on
as cases where problems will arise trying to handle signals - let
alone other pinvoke'd code. So I think you are right that it must 
be done by some form of polling approach (not heard of the 
write protection trick you mention before - not quite sure how
that works to only cause one thread to fault though - or do they
all fault and continue until the right thread unprotects it?). The 
managed/unmanaged  transition does seem like an obvious 
place to check - and it  also requires all the EINTR checking you 
mention for appropriate IO calls. Does this also mean every 
mutex lock should be timed so we can check for aborts on the 
timeouts (the pthread man page seems to say any signal should 
not cause the lock call to exit).

How to make this all work on Windows is a different matter.

I'll see what this really involves - but this does seem like the best
approach.

Bernie


----- Original Message ----- 
From: "Varga Zoltan" <vargaz at freemail.hu>
To: <mono-devel-list at lists.ximian.com>
Sent: Monday, April 12, 2004 10:31 AM
Subject: RE: [Mono-devel-list] Anyone have ideas on making ThreadAbor


> 
>                                                  Hi,
> 
>    I would advocate using the polling approach to handling async
> exceptions like ThreadAbort. The current approach has many
> problems:
> - since the runtime can be in any state when receiving the
> signal,
>   the handler can only call code which is 'async-signal
> safe'. This is
>   impossible to satisfy in general, since during exception
> handling,
>   filter code can be called which might execute arbitary
> code. Also, 
>   common code like the Boehm GC allocation functions are not
> async
>   safe.
> - locking problems. If the thread holds unmanaged locks and
> it is 
>   aborted, the locks are not released, leading to a deadlock
> later. This
>   is already happening during appdomain unloading. This could be
>   solved by somehow registering which thread holds which
> lock, but
>   I think this is hard to implement and slow. Also, some
> locks, like the
>   GC lock, are outside our control and can't be handled that
> way.
> - Disabling signals is another solution but it is also hard
> to get right,
>   and would hurt performance.
> - It doesn't work on Windows, and don't seem to work on
> Solaris either.
> 
> I think polling can be implemented efficiently:
> - If the thread is in managed code when receiving the
> signal, there is
>    no problem, and the current approach can be used.
> - If the thread is in unmanaged code, then a flag could be
> set which is
>    checked when returning from unmanaged code. Checking the flag
>    can be done in one instruction by writing to a memory
> location which
>    is write protected by runtime when there is a pending
> async exception
>    for the thread/process. Since there is already some
> overhead with
>    managed->unmanaged transitions, this wouldn't hurt
> performance much.
> 
> The other problem with polling is what happens if the thread
> blocks
> indefinitely in unmanaged code. There are two cases here:
> - runtime code which is under our control: this code should
> be written
>    in such a way that it does not block indefinitely, e.g.
> by checking 
>   the return value of system calls, and if it is EINTR, then
> check for async
>   exceptions, and if there is an exception, then return from
> the 
>   native code, and the managed->unmanaged transition code
> will do
>    the rest.
> - native code which is outside of our control like pinvoke:
> There's little
>    that can be done here. If the thread does not return to
> managed 
>    code, then it can't be aborted.
> 
> So this approach has the disadvantage that it doesn't always
> work, i.e.
> some threads can't be aborted. But it is much safer than the
> current
> approach, i.e. it doesn't lead to deadlocks and crashes.
> 
>                                                           
> Zoltan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: mono-devel-list-admin at lists.ximian.com
> > [mailto:mono-devel-list-admin at lists.ximian.com]On Behalf
> Of ext Bernie
> > Solomon
> > Sent: Monday, April 12, 2004 6:57 PM
> > To: mono-devel-list at lists.ximian.com
> > Subject: [Mono-devel-list] Anyone have ideas on making
> > ThreadAbortException robust
> > 
> > 
> > 
> > In running various tests I believe handling
> ThreadAbortException
> > isn't robust at present. Unless there is something going
> > on I haven't realized and hopefully someone will correct me.
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>