Top-level TVars

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Top-level TVars

Joel Reymont
Can this be done now or is this a GHC 6.5 feature?

My combination of unsafePerformIO with atomically $ newTVar does not  
seem to be working.

        Thanks, Joel

P.S. What is the ETA for 6.5?
       
On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote:
 >
 > It turns out to be easy to provide
 >
 > newTVarIO :: a -> IO (TVar a)
 >
 > which you can call from inside 'unsafePerformIO'.  That means you can
 > allocate top-level TVars without fuss.
 >

--
http://wagerlabs.com/





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Tomasz Zielonka
On Tue, Dec 13, 2005 at 06:08:23PM +0000, Joel Reymont wrote:
> Can this be done now or is this a GHC 6.5 feature?
>
> My combination of unsafePerformIO with atomically $ newTVar does not  
> seem to be working.

Here is an example how you can initialize a top-level STM variable.
    http://www.uncurry.com/repos/TimeVar/TimeVar.hs
It just forks a new thread inside unsafePerformIO, it runs "atomically"
in it and passes the result through ordinary MVar.

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Peyton Jones
In reply to this post by Joel Reymont
newTVarIO in the HEAD, and therefore it's in any nightly-build snapshot,
which you can freely download.

The next major release will be 6.6, but it's a few months off.
Meanwhile I hope you can use the workaround that Tomasz posted.

Simon

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of Joel
| Reymont
| Sent: 13 December 2005 18:08
| To: Haskell-Cafe Cafe
| Subject: [Haskell-cafe] Top-level TVars
|
| Can this be done now or is this a GHC 6.5 feature?
|
| My combination of unsafePerformIO with atomically $ newTVar does not
| seem to be working.
|
| Thanks, Joel
|
| P.S. What is the ETA for 6.5?
|
| On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote:
|  >
|  > It turns out to be easy to provide
|  >
|  > newTVarIO :: a -> IO (TVar a)
|  >
|  > which you can call from inside 'unsafePerformIO'.  That means you
can
|  > allocate top-level TVars without fuss.
|  >
|
| --
| http://wagerlabs.com/
|
|
|
|
|
| _______________________________________________
| Haskell-Cafe mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Marlow
In reply to this post by Joel Reymont
On 13 December 2005 18:34, Tomasz Zielonka wrote:

> On Tue, Dec 13, 2005 at 06:08:23PM +0000, Joel Reymont wrote:
>> Can this be done now or is this a GHC 6.5 feature?
>>
>> My combination of unsafePerformIO with atomically $ newTVar does not
>> seem to be working.
>
> Here is an example how you can initialize a top-level STM variable.
>     http://www.uncurry.com/repos/TimeVar/TimeVar.hs
> It just forks a new thread inside unsafePerformIO, it runs
> "atomically" in it and passes the result through ordinary MVar.

A cheaper way is just to seq the top-level TVar at the beginning of
Main.main.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Tomasz Zielonka
On Wed, Dec 14, 2005 at 09:51:16AM -0000, Simon Marlow wrote:
> > Here is an example how you can initialize a top-level STM variable.
> >     http://www.uncurry.com/repos/TimeVar/TimeVar.hs
> > It just forks a new thread inside unsafePerformIO, it runs
> > "atomically" in it and passes the result through ordinary MVar.
>
> A cheaper way is just to seq the top-level TVar at the beginning of
> Main.main.

Yes, I tried that approach. However, imagine telling users of
your library to do that in every program (withSocketsDo comes
to mind).

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Marlow
In reply to this post by Joel Reymont
On 14 December 2005 09:57, Tomasz Zielonka wrote:

> On Wed, Dec 14, 2005 at 09:51:16AM -0000, Simon Marlow wrote:
>>> Here is an example how you can initialize a top-level STM variable.
>>>     http://www.uncurry.com/repos/TimeVar/TimeVar.hs
>>> It just forks a new thread inside unsafePerformIO, it runs
>>> "atomically" in it and passes the result through ordinary MVar.
>>
>> A cheaper way is just to seq the top-level TVar at the beginning of
>> Main.main.
>
> Yes, I tried that approach. However, imagine telling users of
> your library to do that in every program (withSocketsDo comes
> to mind).

Well sure, but it's only a temporary problem.  And you also have to tell
them to use {-# NOINLINE #-} and -fno-cse :-)

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Tomasz Zielonka
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 #-} ?

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Joel Reymont
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 #-} ?

--
http://wagerlabs.com/





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Marlow
In reply to this post by Joel Reymont
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Tomasz Zielonka
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?

Ah, yes. Thanks for explanation.

> 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.

How about a new pragma:

{-# OPTIMIZER_HANDS_OFF var1 #-}

;-)

Best regards
Tomasz

--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Top-level TVars

Joel Reymont

> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Peyton Jones
In reply to this post by Joel Reymont
Yes, they do

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] 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
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Top-level TVars

Simon Marlow
In reply to this post by Joel Reymont
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe