- Haskell-Cafe - Haskell.org

RE: [Haskell] TArray?
by Simon Marlow 15 Dec '05

15 Dec '05

On 13 December 2005 14:52, Jan-Willem Maessen wrote: > On Dec 13, 2005, at 8:46 AM, Simon Marlow wrote: >> [In response to another plea for TArrays] > >> In the past I have used arrays of TVars, as Thomasz suggested. It >> would indeed be better to have a primitive STM array, the only >> problem with this is the extra complexity. One simplifying >> assumption is that it should consider changes at the level of the >> whole array, rather than per-element (otherwise you'd use an array >> of TVars). > > Actually, in that case it might be more useful to have a TMVar > containing an array. But I suspect the need for this use case is > small. I know a ton of uses for transactionally-updated arrays for > which the goal is to permit concurrent access to independent array > elements (concurrent hash tables come to mind as an obvious use case > where transactions make life vastly simpler). > > You might ask Tim Harris whether there's a reasonably simple, clever > way to do this > using arrays + CAS. I believe such a trick exists---you might end up > waking too many threads on a write, but you'd get read/write > concurrency at least. One simple plan is to log writes at the element level during a transaction (i.e. don't copy the whole array), but don't track *waiting* at the element level, so a thread waiting on a TArray will get woken up whenever the array is modified. You get read/write concurrency this way. Committing a transaction still has to lock the whole array during the update. Tim, do you know of any better schemes? Cheers, Simon

3 2

Re: Announcing Djinn, version 2004-12-11, a coding wizard
by oleg＠pobox.com 15 Dec '05

15 Dec '05

Stefan Monnier wrote: > I expected at first you were doing some funky type class molestation > so you can use "djinn" in your code and let Haskell fill it in. That has already been done: De-typechecker: converting from a type to a term http://www.haskell.org/pipermail/haskell/2005-March/015423.html ``We ask the Haskell typechecker to derive us a function of the specified type. We get the real function, which we can then apply to various arguments. ... Informally, we converted from `undefined' to defined. It must be emphasized that no modifications to the Haskell compiler are needed, and no external programs are relied upon. In particular, however surprising it may seem, we get by without `eval' -- because Haskell has reflexive facilities already built-in.''

2 1

RE: Re[2]: [Haskell-cafe] Unbound threads and FFI
by Simon Marlow 15 Dec '05

15 Dec '05

On 14 December 2005 18:04, Bulat Ziganshin wrote: > Hello Simon, > > Wednesday, December 14, 2005, 7:39:43 PM, you wrote: > >> Do other Haskell threads get blocked during an FFI call? > >> | safe unsafe >> --------------+---------------- >> -threaded | NO YES >> no -threaded | YES YES > > there is also `threadsafe` specifier. i don't understand from the docs > what it exactly means? > > ghc commentary says: > > To signal that you want an external call to be serviced by a separate > OS thread, you have to add the attribute threadsafe to a foreign > import declaration, i.e., > > foreign import "bigComp" threadsafe largeComputation :: Int -> IO () > > The distinction between 'safe' and thread-safe C calls is made so that > we may call external functions that aren't re-entrant but may cause a > GC to occur. > > The threadsafe attribute subsumes safe. threadsafe is deprecated; it is currently exactly the same as safe. We thought at one time that it would be useful to have the distinction, but it turned out to be impractical to implement safe that wasn't also threadsafe. Cheers, Simon

1 0

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 15 Dec '05

15 Dec '05

On 14 December 2005 20:39, Joel Reymont wrote: >> On Wed, Dec 14, 2005 at 02:17:17PM -0000, Simon Marlow wrote: >>> Suppose you create two top-level IORefs with the same type, like >>> this: >>> >>> var1 = unsafePerformIO $ newIORef 0 >>> var2 = unsafePerformIO $ newIORef 0 >>> >>> GHC's CSE optimisation will common these up - after all, it's the >>> same expression, so it must yield the same result, right? > > Do these have to be within the same module for the CSE optimization > to kick in? Right now, yes. But there's no guarantee that GHC might not get cleverer in the future. We're skating on really thin ice here. I'm not particularly keen on re-opening the discussion about top-level IO, but we do need *something* better. Cheers, Simon

1 0

RE: [Haskell-cafe] Top-level TVars
by Simon Peyton-Jones 15 Dec '05

15 Dec '05

Yes, they do | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 14 December 2005 20:39 | To: Tomasz Zielonka | Cc: Simon Marlow; Haskell-Cafe Cafe | Subject: Re: [Haskell-cafe] Top-level TVars | | | > On Wed, Dec 14, 2005 at 02:17:17PM -0000, Simon Marlow wrote: | >> Suppose you create two top-level IORefs with the same type, like | >> this: | >> | >> var1 = unsafePerformIO $ newIORef 0 | >> var2 = unsafePerformIO $ newIORef 0 | >> | >> GHC's CSE optimisation will common these up - after all, it's the | >> same | >> expression, so it must yield the same result, right? | | Do these have to be within the same module for the CSE optimization | to kick in? | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

[Haskell-cafe] Announcing Djinn, version 2004-12-11, a coding wizard
by Lennart Augustsson 15 Dec '05

15 Dec '05

Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart

4 4

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 10:11, Joel Reymont wrote: > I'm a bit lost in the discussion. Why do I need -fno-cse and how do I > seq at the top-level? > > On Dec 14, 2005, at 10:05 AM, Tomasz Zielonka wrote: > >> On Wed, Dec 14, 2005 at 10:03:42AM -0000, Simon Marlow wrote: >>> Well sure, but it's only a temporary problem. And you also have to >>> tell them to use {-# NOINLINE #-} and -fno-cse :-) >> >> -fno-cse is also neccesary? Oops, I didn't know that. Can I simply >> place it in {-# OPTIONS -fno-cse #-} ? Suppose you create two top-level IORefs with the same type, like this: var1 = unsafePerformIO $ newIORef 0 var2 = unsafePerformIO $ newIORef 0 GHC's CSE optimisation will common these up - after all, it's the same expression, so it must yield the same result, right? To turn this off, we use -fno-cse. It's good practice to use -fno-cse whenever you use top-level mutable objects of any kind. You can put it in the source file: {-# OPTIONS_GHC -fno-cse #-} at the top of your file. Cheers, Simon

3 2

RE: [Haskell-cafe] killThread and FFI calls
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 15:35, Joel Reymont wrote: > On Dec 14, 2005, at 3:22 PM, Simon Marlow wrote: > >> On 14 December 2005 14:26, Joel Reymont wrote: >> >>> How does killThread work with FFI calls? What happens at the low >>> level when a thread is blocked on an FFI call and received a >>> KillThread exception? Does it exit immediately via some GHC magic or >>> is the exception caught when the FFI call returns? >> >> The latter. > > Does this change if I kill a thread that's blocked on I/O in a > threaded runtime? > > Does it get cleaned up immediately? A thread blocked on ordinary Handle-based I/O can be killed, because blocked Handle I/O is implemented using communication with the I/O manager thread, so it isn't an FFI call under the hood. Cheers, Simon

1 0

RE: [Haskell-cafe] killThread and FFI calls
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 14:26, Joel Reymont wrote: > How does killThread work with FFI calls? What happens at the low > level when a thread is blocked on an FFI call and received a > KillThread exception? Does it exit immediately via some GHC magic or > is the exception caught when the FFI call returns? The latter. Cheers, Simon

2 1

RE: [Haskell-cafe] Unbound threads and FFI
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 14:37, Joel Reymont wrote: > How do unbound threads play with FFI? According to Simon PJ, each > foreign call will get its own OS thread if its blocked. > > How does GHC determine if the call is blocked? Does each call get its > own OS thread from the start? Sometime later? When a thread exits Haskell to make an FFI call, another OS thread takes over running the other Haskell threads. If we don't have another OS thread available, we start one. > Does this depend on the safe/unsafe specs of the foreign call? this only happens for safe calls, not unsafe. > Does the above change if a threaded/non-threaded runtime is in use? this only happens in the -threaded RTS, in the non-threaded RTS a FFI call will block all the other Haskell threads. Cheers, Simon

2 1