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] |
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>