Re: mask in waitQSem
On 14/11/2014 21:23, Yuras Shumovich wrote: I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74 Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wrote that code. It looks like mask_ is important, otherwise an async exception might leave the MVar empty, no? We can't assume that waitQSem is always called inside a mask_, so it does its own mask_. Cheers, Simon I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: mask in waitQSem
On 14/11/2014 21:30, Brandon Allbery wrote: On Fri, Nov 14, 2014 at 4:23 PM, Yuras Shumovich shumovi...@gmail.com mailto:shumovi...@gmail.com wrote: Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I thought QSem was known to be completely unsafe and http://hackage.haskell.org/package/SafeSemaphore was recommended instead, with QSem and friends slated for removal? FUD! :) I revamped it for 7.6 rather than remove it, it's safe and fast now. Cheers, Simon In any case, there are probably leftover attempts to make it safe, yes. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com mailto:allber...@gmail.com ballb...@sinenomine.net mailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Garbage collection
On 18/11/2014 18:03, Mathieu Boespflug wrote: On 18 November 2014 16:59, Simon Peyton Jones simo...@microsoft.com wrote: Isn't it this simple: the Static Pointer Table must be a source of roots for the garbage collector. Of course! An item in the SPT may be looked up at any time. As Facundo says, the existence of the SPT would solve everything. But we haven't quite figured out how to create a simple SPT yet, so were wondering whether there is an existing generic mechanism to register new GC roots. Yes - the generic mechanism is StablePtrs, so you're on the right lines. Even when you have an SPT you'll probably need to make a StablePtr to it (though I haven't been following the discussion so just ignore me if I'm wrong here). Cheers, Simon I guess there is no better solution but to just create an SPT, even if we don't yet have TypeRep's to put in it. With an SPT, and under the assumption of everyone sharing the same binary in the distributed system, there will be no need to hold on to *all* CAF's - just the ones that are known to have a StaticPointer created for them at compile time. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: mask in waitQSem
On Mon, 2014-11-24 at 10:09 +, Simon Marlow wrote: On 14/11/2014 21:23, Yuras Shumovich wrote: I was reviewing some exception handling code in base library, and I found this line: https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74 Here mask is used, but I looks completely useless for me. waitQSem itself should be called with async exceptions masked, otherwise there is no way to prevent resource leak. Do anyone know why mask is used here? I wrote that code. It looks like mask_ is important, otherwise an async exception might leave the MVar empty, no? We can't assume that waitQSem is always called inside a mask_, so it does its own mask_. Hmm, yes, you are right. Note, that in case of failure (and without external `mask`) it is not possible to determine, whether a unit of resource was reserved or not. It makes the particular instance of `QSem` unusable anymore, and we have to create other one. Probably there are situations where it is OK though. Thanks, Yuras Cheers, Simon I wonder whether an author of the code tried to do something different, so there actually can be a bug hidden here. Probably uninterruptibleMask_ should be used here? (I don't think so though.) Thanks, Yuras ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote: linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' Herbert, perhaps this is integer-gmp2 breakage? ...can't rule it out, but I haven't seen that failure anywhere else so far (including http://haskell.inf.elte.hu/builders/) and can't reproduce it myself either :-/ Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
On 11/24/14 01:50 PM, Herbert Valerio Riedel wrote: On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote: linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' Herbert, perhaps this is integer-gmp2 breakage? ...can't rule it out, but I haven't seen that failure anywhere else so far (including http://haskell.inf.elte.hu/builders/) and can't reproduce it myself either :-/ Have you tested RHEL 6.x? IIRC it is also using older GMP like Solaris... Also this is probably not tested on any builder... Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
Carter
That smells wrong to me. These flags have a very carefully defined meaning; see
Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs
If you say it has side effects when it doesn’t, you’ll confuse your successor
reading the code in five years time.
Better to find out what is going on and why. Might you do that? What
transformation invalidates the let/app invariant? Make a small test case, use
–dverbose-core2core –ddump-occur-anal –ddump-inlinings. I would far rather
that than install a land-mine in the code.
Simon
From: Carter Schonwald [mailto:carter.schonw...@gmail.com]
Sent: 24 November 2014 00:54
To: Edward Kmett
Cc: ghc-devs@haskell.org; Simon Peyton Jones; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that
acts on an unevaluated argument?
woot, solved it, at least in a way thats OK for now.
if I mark the prefetchValue operations as has_side_effects=True, the core lint
failure goes away! I'm not sure if thats the right semantics in the long term,
but it does give me a simple way to make sure it works safely for 7.10
pardon all the noise
-Carter
On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
ok, i'm getting a let/app invariant failure when i build my test case with O1
or O2 but not without
http://lpaste.net/114881
any help would be appreciated on how to address that
On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
yup, i have that!
wrapFetch prefetchValue0# (error this shouldn't get evaluated)
in the test suite!
in contrast
wrapFetch prefetchValue0# $! (error this shouldn't get evaluated) does
explode
shall I add a should fail test with the latter? (it doesn't seem worthwhile)
On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett
ekm...@gmail.commailto:ekm...@gmail.com wrote:
Maybe test for laziness in the argument by just putting something in that goes
boom when forced, e.g. 'undefined'?
On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald
carter.schonw...@gmail.commailto:carter.schonw...@gmail.com wrote:
Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a prefetchValue primop that prefetchs the memory location of a
lifted heap value
namely
several operations of the following form
primop PrefetchValueOp1 prefetchValue1# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd] topRes }
I'd like some feedback on the strictness information design by someone who's
familiar with how that piece of GHC. the idea being that prefetchValue is lazy
in its polymorphic argument (it doesn't force it, it just does a prefetch on
the heap location, which may or may not be evaluated).
https://phabricator.haskell.org/D350
is the code in question. And i *believe* i'm testing for being lazy in that
argument correctly.
thoughts?
many thanks!
-Carter
___
ghc-devs mailing list
ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Diff grouping question
I’d put them all in one Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan Kim Zimmerman Sent: 22 November 2014 13:58 To: ghc-devs@haskell.org Subject: Diff grouping question I am picking up some minor updates required for the API annotations, relating to documentation inaccuracies, and some missing annotations needing to be captured in the parser. Should these go into separate Phab diffs, or can I just put them all in one? Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
when i run
./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -S -fforce-recomp
-ddump-simpl -ddump-to-file –dverbose-core2core –ddump-occur-anal
–ddump-inlinings
i get
target ‘–dverbose-core2core’ is not a module name or a source file
what am I doing wrong in this CLI invocation?
On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Carter
That smells wrong to me. These flags have a very carefully defined
meaning; see
Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs
If you say it has side effects when it doesn’t, you’ll confuse your
successor reading the code in five years time.
Better to find out what is going on and why. Might you do that? What
transformation invalidates the let/app invariant? Make a small test case,
use –dverbose-core2core –ddump-occur-anal –ddump-inlinings. I would far
rather that than install a land-mine in the code.
Simon
*From:* Carter Schonwald [mailto:carter.schonw...@gmail.com]
*Sent:* 24 November 2014 00:54
*To:* Edward Kmett
*Cc:* ghc-devs@haskell.org; Simon Peyton Jones; Joachim Breitner
*Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
primop that acts on an unevaluated argument?
woot, solved it, at least in a way thats OK for now.
if I mark the prefetchValue operations as has_side_effects=True, the core
lint failure goes away! I'm not sure if thats the right semantics in the
long term, but it does give me a simple way to make sure it works safely
for 7.10
pardon all the noise
-Carter
On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
ok, i'm getting a let/app invariant failure when i build my test case
with O1 or O2 but not without
http://lpaste.net/114881
any help would be appreciated on how to address that
On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
yup, i have that!
wrapFetch prefetchValue0# (error this shouldn't get evaluated)
in the test suite!
in contrast
wrapFetch prefetchValue0# $! (error this shouldn't get evaluated)
does explode
shall I add a should fail test with the latter? (it doesn't seem
worthwhile)
On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett ekm...@gmail.com wrote:
Maybe test for laziness in the argument by just putting something in
that goes boom when forced, e.g. 'undefined'?
On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a prefetchValue primop that prefetchs the memory location of
a lifted heap value
namely
several operations of the following form
primop PrefetchValueOp1 prefetchValue1# GenPrimOp
a - State# s - State# s
with strictness = { \ _arity - mkClosedStrictSig [botDmd, topDmd]
topRes }
I'd like some feedback on the strictness information design by someone
who's familiar with how that piece of GHC. the idea being that
prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
just does a prefetch on the heap location, which may or may not be
evaluated).
https://phabricator.haskell.org/D350
is the code in question. And i *believe* i'm testing for being lazy in
that argument correctly.
thoughts?
many thanks!
-Carter
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
Hello Simon, On 2014-11-21 at 14:51:55 +0100, Simon Peyton Jones wrote: I'm getting this for test linker_unload on Linux. I'm sure it's not my fault! But it makes validate fail [...] linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 I've tried this in an Ubuntu 12.04.5 LTS/x86_64 environment, but couldn't reproduce it. I'm quite confident that '__gmpn_rshift' is in fact not missing, otherwise you'd get much more failures (and GHC probably wouldn't even build). I also don't think that Ubuntu 12.04's is too old, as it's a GMP 5.0.2 version afaik. Does `TEST=linker_unload` fail deterministically? Would it be possible to update your `sudo apt-get update` `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream... Finally, if that also doesn't help, can you try cloning a fresh tree via git clone --recursive git://ghc.haskell.org/ghc.git new-folder-name and invoke ./validate inside new-folder-name? HTH, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote: Would it be possible to update your `sudo apt-get update` `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream... I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you should use is probably `sudo apt-get update` `sudo apt-get upgrade` Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: linker_unload
On 2014-11-25 at 08:23:04 +0100, Karel Gardas wrote: On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote: Would it be possible to update your `sudo apt-get update` `sudo apt-get dist-upgrade` your Linux environment with the latest bugfixes to Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already fixed upstream... I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you should use is probably `sudo apt-get update` `sudo apt-get upgrade` http://askubuntu.com/questions/215267/will-apt-get-dist-upgrade-upgrade-my-system-to-newer-version TLDR: no, `apt-get dist-upgrade` will not ugrade away from the 12.04.x branch ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
