[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting

From: John Cowan
Subject: Re: [Chicken-hackers] Minutes of 2012-06-14 IRC meeting
Date: Tue, 19 Jun 2012 09:53:53 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

Felix scripsit:

> The problem is that I would like to keep the base system thread-less
> (with the exception of the primordial thread, naturally). We don't
> need the scheduler until we use srfi-18. One option would be to run
> finalizers in a separate thread once we enable threading and just run
> them in the primordial thread if threading is not enabled yet.

That should be fine: it doesn't trigger the problem, because there are
no locks to screw up either.  This is the nub of what can go wrong:

    Since finalizers can be (and are) run from any thread, and thread
    locks are recursive, if a thread runs a finalizer while it already
    holds a monitor lock, we potentially break synchronization in a
    completely unsuspecting class. If thread locks weren't recursive,
    this would cause deadlock instead.

    The real culprit is the potential running of finalizers by any
    thread. Allowing threads that potentially hold locks to run
    finalizers that may also need to synchronize on monitor locks
    is a very bad thing, potentially violating synchronization
    assumptions or causing deadlock.

John Cowan    address@hidden
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]