[Mono-devel-list] Anyone have ideas on making ThreadAbortException robust
A Rafael D Teixeira
rafaelteixeirabr at hotmail.com
Mon Apr 12 14:57:42 EDT 2004
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
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
>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
>if the thread blocks it will have signals blocked and not respond to
>aborts as it probably should. If the order is:
>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?
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
MSN Messenger: instale grátis e converse com seus amigos.
More information about the Mono-devel-list