Sorry to take a while writing these up and sending them, I got distracted!
Felix popped into #chicken and a quick meeting about the next release occurred. * It was proposed that the next release come real soon now as we've hung around too long. We feel there's known instability in the scheduler, but fixing it will be a new project, the remaining Windows issues don't have enough interested users to fix them, and it's been too long since 4.7.0. * It was also proposed that we should stop calling them "stability branches", which confuses users, and instead make them a new level of point releases. The model will be that we make a release of master whenever we think it's ready (eg, we've fixed all the bugs we're going to fix), and call it A.B.0 (see http://wiki.call-cc.org/release-policy for how this happens); development then starts on the next release (which might be A+1.0.0 or A.B+1.0, depending on how awesome it is; we can also do interim "development snapshot releases" of A.B.1 and up whenever we feel it's useful to do so - see http://wiki.call-cc.org/release-policy again), but any bugs in existing functionality that arise get fixed on master and we periodically publish an A.B.0.1 with them back-ported onto the A.B release branch whenever it seems essential, and an A.B.0.2 when we have some more, etc. This is basically what we do anyway, but we confuse people by calling them stability branches and having the "-st" suffix. So, to clarify, as I understand it, Chicken version numbers mean: A.B.0 (often A.B for short): Stable release A.B.0.X: Even more stable release with bug fixes added; formerly known as A.B.0.X-st A.B.C: Development snapshot of work towards A.B+1 or A+1.0, with exciting new features and new bugs. It's basically a beta! A.B.C.X: If we deem it worthwhile, we can backport bug fixes from master to development snapshot branches, too. Formerly known as A.B.C.X-st Also, we discussed threads and the scheduler, which is an area of the code we have poor confidence in. Alaric proposes to try and simplify the scheduler by making a more functional implementation of the tricky bit, which is deciding when to unblock threads. In effect, we need a procedure that takes a list of blocked threads (blocked on fds or timeouts or both), and a closure that will do the job of select(), and returns a new list of blocked threads (hopefully smaller) and a list of now-runnable threads. That can be used by the actual scheduler (where it will hopefully make things clearer by separating that from the mechanisms of context switching and interrupts), or it can be run from a test harness with a mock select() to check it handles awkward cases correctly. Felix thinks he might have fixed the exceptions-in-finalizers thing, but worries that finalizers should really run in a dedicated thread rather than in arbitrary threads. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
