Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe. On Mar 6, 2007, at 23:18 , David Brown wrote:

Seth Kurtzberg wrote:

...

On Tue, 06 Mar 2007 12:03:05 -0800 David Brown wrote:

...

I've noticed quite a few pages referencing constructs such as:

var :: MVar ([Foo]) var = unsafePerformIO (newMVar ([]))

and the likes. Is there a danger of different uses of 'var' getting new MVars instead of all sharing one.

Having a reliable way to create a piece of global state would be very convenient.

This operation is unsafe by definition. I use it extensively, without problems. The "unsafe" in the name reminds you that there are situations for which the function is inappropriate, but all of my deployed commercial programs have functionality of this sort. Understand the risk, but don't hesitate to use it.

Do you do anything to keep 'var' from getting inlined? I can envision a case where the code would be inlined, and then each use would get a separate MVar.

Thanks, Dave

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Neil Mitchell wrote:

On 3/6/07, Lennart Augustsson wrote:

...

Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe.

Couldn't GHC bake in knowledge about unsafePerformIO, and never inline it? It is a slightly hacky solution, but since unsafePerformIO is pretty much only used in hacks, I think its almost fitting.

It seems to be used a bit more than just as a hack. Many things that interface with the real world, but try to present lazy interfaces have to use it. Maintaining a shared state that doesn't have to be passed around to everything that uses it isn't really a hack. As an example, I would like to have something that performs logging, and is used by many clients. Without the unsafePerformIO, everything has to somehow find and pass around the state of this logging system, whereas with it, it can just allocate one when first needed. Non-strict semantics are kind of a new thing for me. I'm still trying to get a good grasp of what can be lazy, what should live in the IO Monad, and what should have a carefully crafted "bridge" between the two. Things like hGetContents have somewhat set a trend here. Dave

Lennart Augustsson wrote:

I wouldn't like if unsafePerformIO could never be inlined, sometimes you want it inlined for performance. And not all uses are hacky, it's just that when I use it, then burden is on me to convince myself that it is safe.

unsafePerformIO is currently not inlined - there's a NOINLINE pragma on its definition in GHC.IOBase, and some comments in there to explain why. You're right that sometimes you really want it to be inlined - this is why there's a function called inlinePerformIO in Data.ByteString.Base, for example. You'd better really know what you're doing before using that one, though :-) Cheers, Simon