chicken-hackers
[Top][All Lists]
Advanced

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

[Chicken-hackers] PS: Ticket 1231


From: Jörg F . Wittenberger
Subject: [Chicken-hackers] PS: Ticket 1231
Date: Thu, 31 Dec 2015 12:40:32 +0100
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:38.0) Gecko/20100101 Icedove/38.4.0

Am 31.12.2015 um 12:32 schrieb Jörg F. Wittenberger:
> I do understand that there may be some fear that fixing the bug could
> cause some existing (though buggy) chicken code to break, just because
> this hypothetical code would rely on the bug canceling out the bug in
> the other code.  However I don't think such could exist!  Because it may
> be hard to deterministically rely on the bug's existence:  The
> precondition would be 1.) that the mutex involved is _always_ in
> contention when the second mutex-lock! is attempted, thus the locking
> thread has to wait 2.) as long as the second thread taking the lock does
> not terminate, it's only a memory leak 3.) all code not using
> mutex-lock! with the third argument being #f is always safe.

Forgot: 4.) [actually 3. with 3. becoming 4.]

The hypothetical code relying on bugs canceling each other out must
furthermore rely on the fact that the mutex is now no longer usable and
an abandoned-mutex-exception will protect the section from being
re-entered.  Again, note that this section will not be protected by this
exception when the mutex was found in unlocked state in step 1.


> 
> 
> 
> So please consider to apply this (probably to master at least, though
> *I* would actually recommend it for _stability_, but I understand as per
> paragraph above, that just you may object here) it is really a road block.
> 
> Thanks you sooo much!
> 
> /Jörg
> 
> _______________________________________________
> Chicken-hackers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> 




reply via email to

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