[Bug-kawa] [bugs #11801] fluid-let problems in the presence of threads

[Per Bothner]

Follow-up Comment #3, bugs #11801 (project kawa):

I think I understand the problem.  It's something I'd been vaguely concerned
about before, without really thinking things through it properly.



There is by default one Environment per thread, and it maps a Symbol (and a
property we can ignore here) to a Location object, which contains the actual
value.  Hence a Location is also normally per-thread, but a Location can
indirect to another Location, possibly belonging to the parent thread.

The compiler caches the Locations in the fields of the module.  My assumption
was that if you used multiple threads, you'd have multiple module instances. 
But this fails in two ways:



(1) If you use module-static.  We need to split up module-static into two
options: "module-single" (assume a single thread) and "module-static" (a
shared module, and global module values, but with per-thread "dynamic
environments").

(2) Even with module-static #f you get a problem if a call to future passes
the current module instance to the child thread, which then reuses the
parent's cached Location objects.  That is the issue with the test-case.



I've been pondering how srfi-39 "parameter objects" relate to fluid
variables.  I think a solution to the current problem is for the module to
cache "parameter objects" (in static fields) instead of thread-specific
Location objects.  I'm working on that.



    _______________________________________________________

This item URL is:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11801>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/