[Mono-devel-list] Anyone have ideas on making ThreadAbortException robust

[A Rafael D Teixeira]

Why not keep track of outstanding locks for every thread and freeing them 
when the thread is aborted?

Just my 2 cents,

Rafael "Monoman" Teixeira
Mono Hacker since 16 Jul 2001 - http://www.go-mono.org/
MonoBrasil Founding Member - Membro Fundador do MonoBrasil 
http://monobrasil.softwarelivre.org
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/


>From: "Bernie Solomon" <bernard at ugsolutions.com>
>To: <mono-devel-list at lists.ximian.com>
>Subject: [Mono-devel-list] Anyone have ideas on making ThreadAbortException 
>robust
>Date: Mon, 12 Apr 2004 09:56:55 -0700
>
>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.
>
>This seems to be because there is nothing that knows
>whether interrupting the current thread is globally safe at any
>given instance. In particular when that thread owns one of the
>global locks in the runtime. The first one I found was the
>one for serializing calls to the handle daemon but the problem
>seems more widespread. If the signal occurs while the lock
>is taken it will never get unlocked and everything locks up.
>
>The two choices seem to be either to work out where to
>disable handling this abort (by use of pthread_sigmask) or
>where to actively enable it (have the signal handler just set
>a flag which is tested in various spots). Disabling in various spots
>means finding those cases - and coming up with a technique
>for handling this which requires a little thought. If the order
>was
>
>         pthread_sigmask
>         pthread_mutex_lock
>
>if the thread blocks it will have signals blocked and not respond to
>aborts as it probably should. If the order is:
>
>         pthread_mutex_lock
>         pthread_sigmask
>
>then if the signal arrives between the two calls we end up not
>freeing the lock unless the signal handling mechanism knows
>which global locks the current thread owns so perhaps the
>signal handler can unlock them before throwing the exception.
>This would require making global locks (at least) special
>so they can be tidied up in the signal handling - and use of
>the simulated CriticalSection api would require modifying.
>
>Polling for abort has the standard sorts of problems with polling
>(this would probably be easier in the interpreter) of performance
>and not responding if something doesn't poll.
>
>Anyone else have any comments on this?
>
>Bernie Solomon
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list

_________________________________________________________________
MSN Messenger: instale grátis e converse com seus amigos. 
http://messenger.msn.com.br