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
On 07.08 13:16, Frederik Eaton wrote:
How would this work together with the FFI?
It wouldn't, at least I wouldn't care if it didn't.
Suddenly breaking libraries that happen to use FFI behind your
back does not seem like a good conservative extension.
I think we should move the discussion
On Tue, Aug 08, 2006 at 04:21:06PM +0300, Einar Karttunen wrote:
On 07.08 13:16, Frederik Eaton wrote:
How would this work together with the FFI?
It wouldn't, at least I wouldn't care if it didn't.
Suddenly breaking libraries that happen to use FFI behind your
back does not seem like
Furthermore, can we move this thread from the Haskell mailing list
(which should not have heavy traffic) to either Haskell-Café, or
the libraries list?
Sure, moving to haskell-cafe.
Frederik
--
http://ofb.net/~frederik/
___
Haskell mailing list
| I have initialized a wiki page:
|
| http://haskell.org/haskellwiki/Thread_local_storage
Great
| 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 agree.
Discussion by email
Furthermore, can we move this thread from the Haskell mailing list
(which should not have heavy traffic) to either Haskell-Café, or
the libraries list?
Sure, moving to haskell-cafe.
Frederik
--
http://ofb.net/~frederik/
___
Haskell-Cafe mailing
On Sun, Aug 06, 2006 at 01:36:15PM +0300, Einar Karttunen wrote:
On 06.08 02:41, Frederik Eaton wrote:
Also, note that my proposal differs in that thread local variables are
not writable, but can only be changed by calling (e.g. in my API)
'withIOParam'. This is still just as general,
| On Sat, Aug 05, 2006 at 02:18:58PM -0400, Robert Dockins wrote:
| Sorry to jump into this thread so late. However, I'd like to take
a moment
| to remind everyone that some time ago I put a concrete proposal for
| thread-local variables on the table.
|
|
On 06.08 04:23, Frederik Eaton wrote:
I also forgot to mention that if you hold on to a ThreadId, it
apparently causes the whole thread to be retained. Simon Marlow
explained this on 2005/10/18:
Actually this problem does not exist in the code.
The problem is encountered if children are tied
On 06.08 02:41, Frederik Eaton wrote:
Also, note that my proposal differs in that thread local variables are
not writable, but can only be changed by calling (e.g. in my API)
'withIOParam'. This is still just as general, because an IORef can be
stored in a thread-local variable, but it makes
On 05.08 19:56, Frederik Eaton wrote:
That doesn't answer the question: What if my application has a need
for several different sets of parameters - what if it doesn't make
sense to combine them into a single monad? What if there are 'n'
layers? Is it incorrect to say that the monadic approach
On 8/5/06, Frederik Eaton [EMAIL PROTECTED] wrote:
Also, note that my proposal differs in that thread local variables are
not writable, but can only be changed by calling (e.g. in my API)
'withIOParam'.
[snip]
and if some library I use decides
to fork a thread behind the scenes, it won't
Maybe I'm misunderstanding your position - maybe you think that I
should use lots of different processes to segregate global state into
separate contexts? Well, that's nice, but I'd rather not. For
instance, I'm writing a server - and it's just not efficient to use a
separate process for
On 05.08 14:32, Frederik Eaton wrote:
If it is documented maybe it could be done at the level of an
implicit parameter?
Do you think implicit parameters are better than TLS?
Implicit parameters are explicit and the type checker
guards that they are not undefined (and thus are safe
in the
Sorry to jump into this thread so late. However, I'd like to take a moment
to remind everyone that some time ago I put a concrete proposal for
thread-local variables on the table.
http://article.gmane.org/gmane.comp.lang.haskell.cafe/11010
I believe this proposal addresses the initialization
As said before the monadic approach can be quite clean. I haven't used
implicit parameters that much, so I won't comment on them.
Perhaps you can give an example? As I said, a single monad won't
suffice for me, because different libraries only know about different
parts of the
Hi Robert,
I looked over your proposal.
I'm not sure if I'm in favor of introducing a new keyword. It seems
unnecessary.
Also, note that my proposal differs in that thread local variables are
not writable, but can only be changed by calling (e.g. in my API)
'withIOParam'. This is still just as
Here is a naive and dirty implementation. The largest problem is that
TypeRep is not in Ord. An alternative approach using Dynamic would be
possible, but I like the connection between the key
and the associated type.
http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/
Not
As for the subject under discussion (thread local state), I am
personally sceptical about it. Why do we need it? Are we talking
about safety or just convenience/API elegance? I've never
encountered a situation where I've needed thread local state,
(but this does not necessarily make it
On 04.08 17:29, Frederik Eaton wrote:
might, in Adrian Hey and Einar Karttunen's world, become:
newMain host environment program_args
network_config locale terminal_settings
stdin stdout stderr = do
hPutStrLn stdout (defaultEncoding locale) Hello world
Actually I have
On 31.07 23:53, Adrian Hey wrote:
Frederik Eaton wrote:
On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
On 31.07 03:18, Frederik Eaton wrote:
4) the library runs the callback code in Tw where the TLS state is
invalid. This is even worse than a global variable in this case.
On 31.07 03:18, Frederik Eaton wrote:
I don't think it's necessarily such a big deal. Presumably the library
with the worker threads will have to be invoked somewhere. One should
just make sure that it is invoked in the appropriate environment, for
instance with the database connection already
On 31.07 14:03, Thomas Conway wrote:
This is why I believe transaction-local variables are a more useful concept.
You are garanteed that there is only one thread accessing them, and
they behave just like ordinary TVars except that each transaction has
its own copy.
This seems like it could be
On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
On 31.07 03:18, Frederik Eaton wrote:
I don't think it's necessarily such a big deal. Presumably the library
with the worker threads will have to be invoked somewhere. One should
just make sure that it is invoked in the
Frederik Eaton wrote:
On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
On 31.07 03:18, Frederik Eaton wrote:
4) the library runs the callback code in Tw where the TLS state is
invalid. This is even worse than a global variable in this case.
If you have threads, and you have
On 29.07 13:25, Frederik Eaton wrote:
I think support for thread-local variables is something which is
urgently needed. It's very frustrating that using concurrency in
Haskell is so easy and nice, yet when it comes to IORefs there is no
way to get thread-local behavior. Furthermore, that one
On Sun, Jul 30, 2006 at 12:35:42PM +0300, Einar Karttunen wrote:
On 29.07 13:25, Frederik Eaton wrote:
I think support for thread-local variables is something which is
urgently needed. It's very frustrating that using concurrency in
Haskell is so easy and nice, yet when it comes to IORefs
On 30.07 11:49, Frederik Eaton wrote:
No, because the thread in which it runs inherits any thread-local
state from its parent.
So we have different threads modifying the thread-local state?
If it is a copy then updates are not propagated.
What about a design with 10 worker threads taking
On Mon, Jul 31, 2006 at 03:54:29AM +0300, Einar Karttunen wrote:
On 30.07 11:49, Frederik Eaton wrote:
No, because the thread in which it runs inherits any thread-local
state from its parent.
So we have different threads modifying the thread-local state?
If it is a copy then updates are
Hi All,
On 7/31/06, Einar Karttunen ekarttun@cs.helsinki.fi wrote:
My main objection to the TLS is that it looks like normal IO,
but changing the thread that evaluates it can break things in ways
that are hard to debug. E.g. we have an application that uses
TLS and passes an IO action to a
Hi,
Sorry to bring up this thread from so long ago.
On Wed, Mar 01, 2006 at 11:53:42AM +, Simon Marlow wrote:
Ashley Yakeley wrote:
Simon Marlow wrote:
Simon I have discussed doing some form of thread-local state, which
covers many uses of implicit
parameters and is much preferable
I would also note that some form of transaction-local variable would
also be really handy for STM usage.
Tom
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
32 matches
Mail list logo
