This is the "back door" into theIO monad, allowingIO computation to be performed at any time. Forthis to be safe, theIO computation should befree of side effects and independent of its environment.

If the I/O computation wrapped inunsafePerformIO performs sideeffects, then the relative order in which those side effects takeplace (relative to the main I/O trunk, or other calls tounsafePerformIO) is indeterminate. Furthermore, when usingunsafePerformIO to cause side-effects, you should take the followingprecautions to ensure the side effects are performed as many times asyou expect them to be. Note that these precautions are necessary forGHC, but may not be sufficient, and other compilers may requiredifferent precautions:

• Use{-# NOINLINE foo #-} as a pragma on any functionfoo that callsunsafePerformIO. If the call is inlined, the I/O may be performed more than once.
• Use the compiler flag-fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (liketest in the example below).
• Make sure that the either you switch off let-floating (-fno-full-laziness), or that the call tounsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls tof. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.

It is less well known thatunsafePerformIO is not type safe. For example:

    test :: IORef [a]    test = unsafePerformIO $ newIORef []    main = do            writeIORef test [42]            bang <- readIORef test            print (bang :: [Char])

This program will core dump. This problem with polymorphic referencesis well known in the ML community, and does not arise with normalmonadic use of references. There is no easy way to make it impossibleonce you useunsafePerformIO. Indeed, it ispossible to writecoerce :: a -> b with thehelp ofunsafePerformIO. So be careful!

This version ofunsafePerformIO is more efficientbecause it omits the check that the IO is only being performed by asingle thread. Hence, when you useunsafeDupablePerformIO,there is a possibility that the IO action may be performed multipletimes (on a multiprocessor), and you should therefore ensure thatit gives the same results each time. It may even happen that oneof the duplicated IO actions is only run partially, and then interruptedin the middle without an exception being raised. Therefore, functionslikebracket cannot be used safely withinunsafeDupablePerformIO.

Since: 4.4.0.0

unsafeInterleaveIO allows anIO computation to be deferred lazily.When passed a value of typeIO a, theIO will only be performedwhen the value of thea is demanded. This is used to implement lazyfile reading, seehGetContents.

A slightly faster version offixIO that may not be safe to use with multiple threads. The unsafety arises when used like this:

 unsafeFixIO $ \r -> do    forkIO (print r)    return (...)

In this case, the child thread will receive aNonTermination exception instead of waiting for the value ofr to be computed.

Since: 4.5.0.0