Certainly, adding hooks to forkIO is possible. Also, providing thread
local data directly is something we could do quite easily (and
efficiently) in GHC.
Cheers,
Simon
On 18 October 2005 19:12, Frederik Eaton wrote:
What about adding support for hooks in forkIO? These could be useful
It seems that you can do this as long as you provide your own version of
forkIO, but not if you want to use the built-in forkIO.
One could argue that getting the parent ThreadId is something that
should be supported natively by forkIO, and I might be inlined to agree.
Unfortunately there are some
What about adding support for hooks in forkIO? These could be useful
for other things as well. Pthreads could be said to have this
functionality:
-- Function: int pthread_atfork (void (*PREPARE)(void), void
(*PARENT)(void), void (*CHILD)(void))
`pthread_atfork' registers handler
On Tue, Oct 18, 2005 at 07:12:13PM +0100, Frederik Eaton wrote:
(Pthreads also has support for thread-specific data:
-- Function: int pthread_setspecific (pthread_key_t KEY, const void
*POINTER)
`pthread_setspecific' changes the value associated with KEY in the
Hi,
I'm trying to get MonadReader-like functionality in the IO monad. It
doesn't appear possible implement it with the interfaces that
Haskell98 or GHC provide. I'm looking for something like thread-local
variables. The interface could be something like this:
newTLRef :: a - IO (TLRef a)
John Meacham suggested that I should be a little more clear about the
semantics I'm seeking. Also, apparently it isn't possible to implement
writeTLRef/modifyTLRef with the data structure I gave:
data TLRef a = TLR a (MVar (Map ThreadId a))
(the first argument is a default value, the second is a
