Ludovic Courtès escreveu: > Hello, > > Andy Wingo <[EMAIL PROTECTED]> writes: > >> ERROR: srfi-18.test: thread-start!: >> thread activates only after start >> - arguments: ((syntax-error "memoization" >> "In file ~S, line ~S: ~A ~S in expression ~S." >> ("/home/lilydev/vc/guile/srfi/srfi-18.scm" 135 >> "Bad binding" ct >> (let (ct (current-thread)) >> [EMAIL PROTECTED] (or (hashq-ref >> thread-exception-handlers ct) >> (hashq-set! thread-exception-handlers ct >> (list initial-handler))))) #f)) > > I'm seeing this as well, but it's a [EMAIL PROTECTED]' here (single-binding > `let's > are memoized as [EMAIL PROTECTED]'): > > ((syntax-error "memoization" > "In file ~S, line ~S: ~A ~S in expression ~S." > ("/home/ludo/src/guile/srfi/srfi-18.scm" 138 > "Bad binding" > ct > ([EMAIL PROTECTED] (ct (#<variable b7d28110 value: > #<primitive-procedure current-thread>>)) > ([EMAIL PROTECTED] (#<variable b7d2ad88 value: > #<primitive-procedure hashq-ref>> > #<variable 839df08 value: > #<weak-key-hash-table 1/31>> [EMAIL PROTECTED]) > (#<variable b7d2adc0 value: #<primitive-procedure > hashq-set!>> #<variable 839df08 value: #<weak-key-hash-table 1/31>> [EMAIL > PROTECTED] (#<variable b7d2c498 value: #<primitive-procedure list>> > #<variable 839d130 value: #<procedure initial-handler (obj)>>)) > ))) > #f)) > > It can be reproduced, but very infrequently, with this program: > > (use-modules (ice-9 threads)) > > (define (foo x y) > (let ((z (+ x y))) > (let ((a (+ z 1))) > (let ((b (- a 2))) > (let ((c (* b 3))) > c))))) > > (define (entry) > (foo 1 2)) > > (for-each (lambda (i) (make-thread entry)) > (iota 123)) > > My explanation is that the `let*' memoizer, aka. `scm_m_letstar ()', is > not thread-safe; it's clearly not atomic, and it's of course not > protected by a mutex or so. > > I can't think of any simple fix. `scm_m_letstar ()' could be made > atomic by having it duplicate the input list instead of modifying it > directly; it could then atomically update the input. However, > allocating cells during memoization wouldn't be a good idea > performance-wise.
I don't understand: memoization is only supposed to happen once for each piece of code, right? So, the cost of it is not that interesting? I remember seeing a very scary looking explanation in eval.c about the evaluator being unlocked but still thread-safe since the result of memoizing was supposed to be confluent (ie. duplicate runs would yield independent results.) /* The Lookup Car Race - by Eva Luator This was added by Marius Vollmer, but at the time, GUILE did not support real posix threads, so any problem may not have manifested itself before. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen