RE: [Haskell] garbage collection of Concurrent Haskell threads?

PROTECTED] On Behalf Of Simon Peyton-Jones Sent: Thursday, 3 January, 2008 14:13 To: Conal Elliott Cc: haskell@haskell.org Subject: RE: [Haskell] garbage collection of Concurrent Haskell threads? The GC discards an MVar when there are only bloc

RE: [Haskell] garbage collection of Concurrent Haskell threads?

hat the same remarks would apply to MVars. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott Sent: 24 December 2007 18:49 To: Simon Peyton-Jones Cc: haskell@haskell.org Subject: Re: [Haskell] garbage collection of Concurrent Haskell threads? Thanks, Simon.

Re: [Haskell] garbage collection of Concurrent Haskell threads?

o hide the Var itself and instead expose reader and writer halves. If there's an analysis problem at all, does that solution make sense? Cheers, - Conal On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > GHC already garbage-collects threads that are blocked o

RE: [Haskell] garbage collection of Concurrent Haskell threads?

GHC already garbage-collects threads that are blocked on an MVar that is otherwise inaccessible (and hence cannot be updated). More precisely, GHC sends the thread an asynchronous exception (ThreadBlocked or something), so that it has a chance to clean up. So perhaps the GC you want is

[Haskell] garbage collection of Concurrent Haskell threads?

lementation of futures in Concurrent Haskell (http://haskell.org/haskellwiki/Reactive), using MVars, and I'm stumped about how to GC non-winning threads in a race between futures ("parallel or"). I'm having winner kill loser, which seems to work fine, though is potentially dangerous

[Haskell] Re: Strange behaviour of forkIO threads

ou'll be able to work around this to some extent by using 2 processors. you want to say "2 OS threads executing Haskell program in parallel" ? i think that 6.6 will support this mode even on single-threading processors? Yes,

Re: [Haskell] Re: Strange behaviour of forkIO threads

GHC 6.6 you'll be able to work around this to some extent by using 2 > processors. you want to say "2 OS threads executing Haskell program in parallel" ? i think that 6.6 will support this mode even on single-threading processors? -- Best regards, Bulat

[Haskell] Re: Strange behaviour of forkIO threads

Maurizio Monge wrote: Hi, i used forkIO to write a 'por' (parallel or) implementation (just a proof of concept), arguments are evaluated in different threads and as soon as one of the threads returns true the other thread is killed and true is returned. If both threads return false the

[Haskell] Strange behaviour of forkIO threads

Hi, i used forkIO to write a 'por' (parallel or) implementation (just a proof of concept), arguments are evaluated in different threads and as soon as one of the threads returns true the other thread is killed and true is returned. If both threads return false the result of the comp

[Haskell] FW: TV06 (Threads Verification) Workshop - New Deadlines, Student Bursaries, ...

Posting on behalf of Ganesh [EMAIL PROTECTED] INTERNATIONAL WORKSHOP on MULTITHREADING in HARDWARE and SOFTWARE (TV06) Sponsored by Microsoft (bursaries for 6 student papers - see URL) August 21-22, 2006, Seattle, WA (after CAV 20

Re: [Haskell] reader-like IO, parents of threads

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

Re: [Haskell] reader-like IO, parents of threads

ks a little more like the Reader monad > > I'm comparing it to. > > > > - What happens on fork? The child thread effectively gets a "copy" of > > each TLRef in its parent. They have the same values, but modifying > > them using withTLRef has no effect on the v

RE: [Haskell] reader-like IO, parents of threads

fe concurrent access) > > Without those functions, it looks a little more like the Reader monad > I'm comparing it to. > > - What happens on fork? The child thread effectively gets a "copy" of > each TLRef in its parent. They have the same values, but modifying

Re: [Haskell] reader-like IO, parents of threads

ey have the same values, but modifying them using withTLRef has no effect on the values in other threads. - Can you pass a TLRef to a different thread? Yes, but the value it holds will not be the same when it is dereferenced in a different thread. The problem with writeTLRef is that if a child

[Haskell] reader-like IO, parents of threads

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) withT

Re: [Haskell] strict vs. lazy state threads

Wolfgang Jeltsch <[EMAIL PROTECTED]> writes: > The problem is that I cannot find an exact specification about what strict > and > lazy means in conjunction with state threads. This example shows a difference: import Control.Monad.ST.Strict -- try Lazy instead of

[Haskell] strict vs. lazy state threads

Hello, http://haskell.org/ghc/docs/latest/html/libraries/base/Control.Monad.ST.html says about the module Control.Monad.ST: This library provides support for strict state threads, as described in the PLDI '94 paper by John Launchbury and Simon Peyton Jones Lazy State Thread

Re: Threads

gt; myaccept g = do a <- accept g > t <- forkIO (f a) > myaccept g > > What to do to have two threads working at the same time. When I am using > myaccept, program is suspending. > > Thanks. > __

Re: Threads

nction > f:: a -> b > > and I need something like this: > > myaccept:: Socket -> IO () > myaccept g = do a <- accept g > t <- forkIO (f a) > myaccept g > > What to do to have two threads working at the

Threads

Hi, I have function f:: a -> b and I need something like this: myaccept:: Socket -> IO () myaccept g = do a <- accept g t <- forkIO (f a) myaccept g What to do to have two threads working at the same time. When I am using myaccept,

Re: how to catch GHC "no threads to run" exception?

In local.haskell, you wrote: > Since I have 3 threads waiting on takeMVar, do I have to wrap > all of them with Exception.catch? Yes. Especially since ghc-5.04, you cannot be sure which of the blocked threads will get killed first: http://haskell.org/pipermail/glasgow-haskell-users/200

Re: how to catch GHC "no threads to run" exception?

On Thu, Aug 01, 2002 at 11:27:06AM +0200, Volker Stolz wrote: > In local.haskell, you wrote: > > test: no threads to run: infinite loop or deadlock? > > My problem is that this behavior is actually desired, but > > how do I catch this exception and do some bookkeeping >

Re: how to catch GHC "no threads to run" exception?

In local.haskell, you wrote: > test: no threads to run: infinite loop or deadlock? > My problem is that this behavior is actually desired, but > how do I catch this exception and do some bookkeeping > (closing external IO, etc.) and then a proper exit? You can wrap the `ta

how to catch GHC "no threads to run" exception?

My program runs 3 threads, and after a few minutes' execution all threads come to a state that they all wait on some MVars, then the program halts with an error: test: no threads to run: infinite loop or deadlock? (test is my program name) My problem is that this behavior is actually de

Re: Haskell threads & pipes & UNIX processes

Fri, 16 Feb 2001 12:16:51 +0100 (CET), Michael Marte <[EMAIL PROTECTED]> pisze: > Indeed, the file produced by the Haskell program is one byte longer > than the file produced by bzip (called from the command line). Sorry, it works for me (bzip2-1.0.1, ghc fresh from CVS). -- __("< Marcin Ko

Re: Haskell threads & pipes & UNIX processes

Hello Marcin, > Thu, 15 Feb 2001 08:50:41 -0800, Julian Seward (Intl Vendor) ><[EMAIL PROTECTED]> pisze: > > > use the foreign import mechanism to make BZ2_bzopen, > > BZ2_bzwrite and BZ2_bzclose available in your program. > > bzlib and zlib wrappers are available in >

Re: Haskell threads & pipes & UNIX processes

Thu, 15 Feb 2001 08:50:41 -0800, Julian Seward (Intl Vendor) <[EMAIL PROTECTED]> pisze: > use the foreign import mechanism to make BZ2_bzopen, > BZ2_bzwrite and BZ2_bzclose available in your program. bzlib and zlib wrappers are available in (for g

RE: Haskell threads & pipes & UNIX processes

| So what's going on? How can the goal be achieved? I don't know, but here's a different suggestion, using bzip2 (you could do the same with zlib for .gz files): use the foreign import mechanism to make BZ2_bzopen, BZ2_bzwrite and BZ2_bzclose available in your program. Then: do bz2 <- bzope

Haskell threads & pipes & UNIX processes

consumer. If the consumer is started first, the consumer blocks because there is no input. So I played around with threads. If both consumer and producer are executed as threads, the program terminates immediately without any output. There seems to be no need to start executing any of the thr

Re: Haskell "threads"

Hello! On Mon, Jul 31, 2000 at 12:27:52AM +, Bill Halchin wrote: > Hello Haskell Community, > Is there a tutorial or simple sample Haskell scripts that > demonstrate the use of Haskell Thread??. I know that Haskell > threads are monad. import Concurrent main = forkIO a

Haskell "threads"

Hello Haskell Community, Is there a tutorial or simple sample Haskell scripts that demonstrate the use of Haskell Thread??. I know that Haskell threads are monad. Regards, Bill Halchin Get Your Private, Free E-mail