Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > This took a lot of effort to debug; printing the rational while > debugging would alter the reduction bit, making the problem go away, > suggesting memory corruption rather than a programming error.
Nasty. > Suppose another thread triggers scm_i_fraction_reduce at the same > time, and reads the partial result of the first scm_i_fraction_reduce. > This is really insidious, as the corruption would happen upon reading > the data, and will show up somewhere completely different. Yep. I think I might have raised that when fractions were introduced, then promptly never did anything about it. My best idea at the time was if fractions are stored unreduced then gc would be a good thread-safe place to look for reductions to save space. I don't know if reduced or unreduced is a better representation. My guess would be that gcds are so horrendously expensive that unreduced is often what you want, if it's do-able. Reducing lazily sounds like the best of both worlds, but as you point out would need multithread protection. > I am about to commit these changes to CVS, and will also commit them > to the GUILE 1.8 branch. Do you have a test case for numbers.test? Not that I doubt the fix, just to illustrate what now works. I took the liberty of adding a NEWS entry too. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
