This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dynamic Bindings; thread-state


Per Bothner <bothner@cygnus.com> wrote:
> What is missing from your proposal are examples of things that
> you could do that you cannot (as easily) do using only
> thread-aware fluid-let.

Unless I missed something, FLUID-LET can't make top-level bindings which
should exist for each and any thread, and about which the code which
creates some new thread doesn't need to know. I'm assuming that this is
usually what one wants, whereas local per-thread bindings can then be
realized easily by re-binding the respective storage location within
each thread, in case it wants to have something different. The two
arguments of the optional initialization procedure allow the initial
value to be computed based on the creator of the new thread, but don't
require such a relation, since that may not always be what one wants.

> Otherwise your proposal loses on the grounds of being more
> complicated (for the user, not implementor),

Hmm, I'm not sure if that's true. As a user, I'd rather care about
having a top-level per-thread variable in an independently developed
library, without bothering the rest of the code about this issue.

> and less compatible with prior art.

I'm not really so sure whether I'd want to call traditional dynamic
variables "art", but would rather stay with quite ordinary assignment
to bindings. (Yes, yes, I know this idiom doesn't tend to imply such
a value judgement, but I couldn't resist ;-) I regard the typical (as
far as I can tell) usage of FLUID-LET as a way to introduce lots of
hidden dependencies in a quite un-modular way (i.e. it nests poorly,
if you assume that lots of independent software components use the
same globals). If some interface requires lots of paramters with some
reasonable defaults, I'd rather make those parameters available with
parametrization-objects (note the plural!), where each concerned piece
of code can maintain its own bag of preferred options, and make the
dependencies between different defaults/deviations explicit. Most of
the time, I'd expect per-thread storage of any kind to be necessary at
the library-implementation level, below the interface-surface, and leave
the remaining thread-specific issues as the natural consequences of the
normal calling sequence, which doesn't jump back and forth between various
threads, but passes its arguments and local bindings around consistently.

> Is there any reason (except possibly efficiency) to have a
> non-thread-aware fluid-let?

I find it conceptually cleaner to decouple allocation of per-thread
storage and the temporary assignment to a variable. Efficiency is in
fact only a minor aspect of my preference - though I'm not neglecting
it either; I'd expect that the abstraction of DEFINE-PER-THREAD can
be mapped to potential thread architectures more efficiently (e.g.
by using virtual memory mapping to designate different pages with
the same logical address, or using one internal mapping table indexed
by some thread-id, or whatever else works best on the system).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>