[Chicken-hackers] Ticket 1231

[Jörg F . Wittenberger]

Hi all,

Wishing you a a pleasant 2016!

May I ask you a favor: could someone please look into applying the patch
attached to ticket 1231.

For this bug is bothering me much.  Not so much for the negligible
memory leak of one cons cell per mutex-lock!, but because:

a) Code using the pattern given in the example "mailbox of depth one" in
srfi-18 right in the description of mutex-lock! breaks under certain
circumstances (for details see the ticket).  I don't think it's a good
idea to force CHICKEN users to write their code different way to work
around the issue.

b) Finding out why the hell it breaks is not going to be easy, because
it may not appear deterministic (even though it is).  Programs hitting
the bug may continue to work for many additional lock operations until
running into an abandoned-mutex-exception.  This semi-determinism could
be really discouraging to new users.

c) This is one of the issues I fixed in a patch I submitted years ago to
chicken-users.  However I did so in a rather huge patch, when I was new
to Chicken and ported my code base to use it.  Since that patch was
"several patches rolled into one" (as Felix put it at that time)
apparently nobody ever bothered to integrate it.  And I never found the
time to unroll those into small patches fixing one issue at a time
(until now).

This is how I came to be the "owner" of this "high load scheduler" egg,
which never materialized, because I don't see a chance to split those
other changes into reasonable patches with the scheduler/srfi-18 being
implemented as it is now.

Therefore I'm planning another path of contribution: I'd like to first
provide a patch which would transform the scheduler and srfi-18 into
modules (which where not available at that time).  This without touching
the logic at all.  Just formally replacing ##sys#-prefixed identifiers
(and for the transition, still providing those for backward
compatibility).  This is going to be a rather huge change.  But that
change will not need so much in-depth review as it should not change
anything but identifiers.

Than we'll see what other changes may be acceptable.

But I can't do this transformation (or at least I can't reasonably test
the result) if it breaks all my code.  I'd first need the real bugs
fixed to have a stable base to work from.



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.



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