[Haskell] thread-local variables

[Frederik Eaton]

Hi Simon,

It is good that you support thread-local variables.

I have initialized a wiki page:

http://haskell.org/haskellwiki/Thread_local_storage

The main difference between my and your proposals, as I see it, is
that your proposal is based on "keys" which can be used for other
things.

I think that leads to an interface which is less natural. In my
proposal, the IOParam type is quite similar to an IORef - it has a
user-specified initial state, and the internal implementation is
hidden from the user - yours differs in both of these aspects.

> * I agree with Robert that a key issue is initialisation.  Maybe it
> should be possible to associate an initialiser with a key.  I have not
> thought this out.

I still don't understand this, so it is not mentioned on the wiki.

> *  A key issue is this: when forking a thread, does the new thread
> inherit the current thread's bindings, or does it get a
> freshly-initialised set.  Sometimes you want one, sometimes the other,
> alas.

I think the inheritance semantics are more useful and also more
general: If I wanted a freshly-initialized set of bindings, and I only
had inheritance semantics, then I could start a thread early on when
all the bindings are in their initial state, and have this thread read
actions from a channel and execute them in sub-threads of itself, and
implement a 'fork' variant based on this. More generally, I could do
the same thing from a sub-thread of the main thread - I could start a
thread with any set of bindings, and use it to launch other threads
with those bindings. In this way, the "initial" set of bindings is not
specially privileged over intermediate sets of bindings.

> On the GHC front, we're going to be busy with 6.6 etc until after ICFP,
> so nothing is going to happen fast -- which gives an opportunity to
> discuss it.  However it's just infeasible for the community at large to
> follow a long email thread like this one. My suggestion would be for the
> interested parties to proceed somewhat as we did with packages.
> (http://hackage.haskell.org/trac/ghc/wiki/GhcPackages)

I have put a page on the wiki summarizing the thread. However, I want
to say that I think that email is a better medium for most ongoing
discussions. (I'm not sure if I may have suggested the opposite
earlier) For those who are not interested in the discussion, it should
be easy in most mail readers to ignore or hide a long thread, or to
skip to the very end of it to get a rough idea of where things stand. 
I think it is a good idea to have proposals on a wiki, though, so that
the product of all agreed-upon amendments and alterations can be
easily referred to.

When discussions happen on a wiki, though, they often take the same
threaded form as email discussions (see Wikipedia) - but, they are
seen by fewer interested people, and the interface is clumsier (for
instance, I can subscribe to email notification when a wiki page
changes - thanks to whomever finally made this possible on
haskell.org, by the way - but I have to read the updated version to
figure out whether the modification was replying to me or another
poster; whereas my mail reader clearly flags messages where I appear
in the recipients list).

Frederik

-- 
http://ofb.net/~frederik/