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 _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers