- Haskell-Cafe - Haskell.org

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

16 Dec '05

On 14 December 2005 15:34, Joel Reymont wrote: > On Dec 14, 2005, at 3:21 PM, Simon Marlow wrote: > >> this only happens in the -threaded RTS, in the non-threaded RTS a FFI >> call will block all the other Haskell threads. > > Just to be absolutely sure... Does the above apply to safe _and_ > unsafe FFI? > > I have been using the non-threaded runtime with unsafe FFI calls > (OpenSSL, Zlib) and I do not believe my runtime was being blocked. > Maybe I just didn't notice it, though. Maybe this little table will help: Do other Haskell threads get blocked during an FFI call? | safe unsafe --------------+---------------- -threaded | NO YES no -threaded | YES YES Cheers, Simon

3 2

QuickCheck arbitrary/co-arbitrary
by Joel Reymont 16 Dec '05

16 Dec '05

Folks, I'm collecting examples of QuickCheck arbitrary/co-arbitrary definitions, the more complex the better. Please point me to any or send them if you are willing to! Also, is there a cood explanation of co-arbitrary someplace? Thanks, Joel -- http://wagerlabs.com/

2 1

RE: [Haskell-cafe] Unbound threads and FFI
by Simon Peyton-Jones 16 Dec '05

16 Dec '05

Did you read the paper Extending the Haskell Foreign Function Interface with Concurrency, described in the GHC Wiki page about concurrency? It'd be a good start http://hackage.haskell.org/trac/ghc/wiki/GhcConcurrency Please do improve it. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 14 December 2005 14:37 | To: Haskell-Cafe Cafe | Subject: [Haskell-cafe] Unbound threads and FFI | | 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? Does this depend on the | safe/unsafe specs of the foreign call? | | Does the above change if a threaded/non-threaded runtime is in use? | | Thanks, Joel | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

official Cabal / Hackage wiki
by Isaac Jones 16 Dec '05

16 Dec '05

The new Cabal / Hackage wiki and bug tracking system is at: http://hackage.haskell.org/trac/hackage [1] Please report any Cabal (or HackageDB, cabal-get, etc) bugs there with "new ticket". Trac is pretty neat, you can inter-like wiki pages and tickets, as well as source code. Please feel free to start editing pages and adding information about Cabal. peace, isaac [1] Why the hackage...hackage redundancy? Well I'm basically hoping to roll out the "hackage" server as a community development site. As such, we have http://hackage.haskell.org/trac/ghc as well :)

1 0

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

15 Dec '05

On 15 December 2005 13:17, Sebastian Sylvan wrote: > Anyway, the main gist of my original post was that TArrays should be > in the libraries, so that I can safely use it without having to send > along my own implementation each time (and potentially colliding with > someone else's implementation down the line). When/if a primitve > TArray is implemented, the Array-of-Tvars-approach could just be > replaced, and all programs which use the TArray would get an automatic > speed-boost. I like it when someone asks for something we've already done :-) http://www.haskell.org//pipermail/cvs-libraries/2005-December/004731.htm l Cheers, Simon

2 1

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