[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
>