Ticket #2095: unsafePerformIO.dpatch

File unsafePerformIO.dpatch, 10.9 KB (added by duncan, 8 years ago)
Line 
1
2New patches:
3
4[Export unsafeDupablePerformIO/InterleaveIO from System.IO.Unsafe
5Duncan Coutts <duncan@haskell.org>**20080109165726
6 These are variants of unsafePerformIO/InterleaveIO that GHC provides that are
7 faster but provide no locking protection for SMP. For non-GHC they are defined
8 to be the ordinary unsafePerformIO/InterleaveIO.
9] {
10hunk ./System/IO/Unsafe.hs 20
11+
12+   -- ** Even less safe variants
13+   unsafeDupablePerformIO,    -- :: IO a -> a
14+   unsafeDupableInterleaveIO, -- :: IO a -> IO a
15hunk ./System/IO/Unsafe.hs 27
16-import GHC.IOBase (unsafePerformIO, unsafeInterleaveIO)
17+import GHC.IOBase (unsafePerformIO, unsafeInterleaveIO,
18+                   unsafeDupablePerformIO, unsafeDupableInterleaveIO)
19hunk ./System/IO/Unsafe.hs 43
20+
21+#if !__GLASGOW_HASKELL__
22+unsafeDupablePerformIO :: IO a -> a
23+unsafeDupablePerformIO = unsafePerformIO
24+
25+unsafeDupableInterleaveIO :: IO a -> IO a
26+unsafeDupableInterleaveIO = unsafeInterleaveIO
27+#endif
28}
29
30[Export unsafeInlinePerformIO from System.IO.Unsafe
31Duncan Coutts <duncan@haskell.org>**20080109173201
32 This variant is so unsafe it's quite terrifying. We use it in ByteString but
33 only very carefully and we've been bitten a couple times.
34] {
35hunk ./System/IO/Unsafe.hs 24
36+
37+   -- ** Extremely unsafe variant
38+   unsafeInlinePerformIO,     -- :: IO a -> a
39hunk ./System/IO/Unsafe.hs 54
40+
41+-- | This variant of 'unsafePerformIO' is quite /mind-bogglingly unsafe/. It
42+-- unstitches the dependency chain that holds the IO monad together and breaks
43+-- all your ordinary intuitions about IO, sequencing and side effects. Avoid
44+-- it unless you really know what you are doing.
45+--
46+-- It is only safe for operations which are genuinely pure (not just
47+-- externally pure) for example reading from an immutable foreign data
48+-- structure. In particular, you should do no memory allocation inside an
49+-- 'unsafeInlinePerformIO' block. This is because an allocation is a constant
50+-- and is likely to be floated out and shared. More generally, any part of any
51+-- IO action that does not depend on a function argument is likely to be
52+-- floated to the top level and have its result shared.
53+--
54+-- It is more efficient because in addition to the checks that
55+-- 'unsafeDupablePerformIO' omits, we also inline. Additionally we do not
56+-- pretend that the body is lazy which allows the strictness analyser to see
57+-- the strictness in the body. In turn this allows some re-ordering of
58+-- operations and any corresponding side-effects.
59+--
60+-- With GHC it compiles to essentially no code and it exposes the body to
61+-- further inlining.
62+--
63+{-# INLINE unsafeInlinePerformIO #-}
64+unsafeInlinePerformIO :: IO a -> a
65+#ifdef __GLASGOW_HASKELL__
66+unsafeInlinePerformIO (IO m) = case m realWorld# of (# _, r #) -> r
67+#else
68+unsafeInlinePerformIO = unsafePerformIO
69+#endif
70}
71
72Context:
73
74[FIX #1936: hGetBufNonBlocking was blocking on stdin/stdout/stderr
75Simon Marlow <simonmar@microsoft.com>**20080124092203]
76[The default uncaught exception handler was adding an extra \n
77Simon Marlow <simonmar@microsoft.com>**20080124091216]
78[add comment about lack of _chsize_s()
79Simon Marlow <simonmar@microsoft.com>**20080123131248]
80[Windows: large file support for hFileSize and hSeek (#1771)
81Simon Marlow <simonmar@microsoft.com>**20080123102904
82 
83 
84]
85[Export topHandler, topHandlerFastExit from GHC.TopHandler
86Ian Lynagh <igloo@earth.li>**20080120182429
87 We now use one of these in ghc when running with ghc -e
88]
89[haddock attributes for haddock-2.0
90Ross Paterson <ross@soi.city.ac.uk>**20080120022308]
91[Data.List.sort: force elements from start to end.
92Bertram Felgenhauer <int-e@gmx.de>**20071121101458
93 this prevents a stack overflow on  sort (take 10^6 [1..])
94]
95[Fix comment on GHC.Ptr.minusPtr
96simonpj@microsoft.com**20080109114736]
97[Remove redundant imports of GHC.Err
98simonpj@microsoft.com**20080104091314
99 
100 GHC.Base SOURCE-imports GHC.Err, and re-exports 'error'.  So
101 other modules need only import GHC.Base.
102 
103 This doesn't change the fact that these other modules are all compiled
104 before GHC.Err, so they are all part of the module loop that starts with
105 GHC.Base and finishes with GHC.Err.  But it does reduce the occurrence
106 of those SOURCE imports.
107 
108]
109[Tuple tycons have parens around their names
110simonpj@microsoft**20071220171812
111 
112 The name of the pair TyCon, in the Typeable instance,
113 should be "(,)" not ",".
114 
115 Don't merge to 6.8; it's a minor API change.
116 
117]
118[Add groupWith, sortWith, the, to support generalised list comprehensions
119simonpj@microsoft.com**20071220111929
120 
121   This the base-library patch to support the main compiler patch
122      Implement generalised list comprehensions
123   
124   It just adds three functions to GHC.Exts.
125 
126]
127[Add GHC.Prim to exposedModules in the Haddock 0.x hook
128David Waern <david.waern@gmail.com>*-20071209173931
129 
130 Please merge to the stable branch
131]
132[Add GHC.Prim to exposedModules in the Haddock 0.x hook
133David Waern <david.waern@gmail.com>**20071209173931
134 
135 Please merge to the stable branch
136]
137[Simplify the GHC.Prim hack in base.cabal/Setup.hs
138Ian Lynagh <igloo@earth.li>**20071202215758]
139[Implement 'openTempFile' for nhc98.
140Malcolm.Wallace@cs.york.ac.uk**20071207133335]
141[docs: describe the changes to forkIO, and document forkOnIO
142Simon Marlow <simonmar@microsoft.com>**20071205091423]
143[doc only: use realToFrac instead of fromRational.toRational
144Simon Marlow <simonmar@microsoft.com>**20071205091334]
145[Add singletonP to GHC.PArr
146Roman Leshchinskiy <rl@cse.unsw.edu.au>**20071205220859]
147[FIX #1621: bug in Windows code for getCPUTime
148Simon Marlow <simonmar@microsoft.com>**20071205120118
149 We were reading the components of FILETIME as CLong, when they should
150 be unsigned.  Word32 seems to be the correct type here.
151]
152[protect console handler against concurrent access (#1922)
153Simon Marlow <simonmar@microsoft.com>**20071204153940]
154[protect against concurrent access to the signal handlers (#1922)
155Simon Marlow <simonmar@microsoft.com>**20071204110817]
156[restore fdToHandle' to avoid breaking clients (#1109)
157Simon Marlow <simonmar@microsoft.com>**20071130135122
158 
159]
160[note about how to convert CTime (aka EpochTime) to UTCTime
161Simon Marlow <simonmar@microsoft.com>**20071130101648]
162[Fix some URLs
163Ian Lynagh <igloo@earth.li>**20071126214213]
164[Fix some links in haddock docs
165Ian Lynagh <igloo@earth.li>**20071126184428]
166[Don't try to make haddock links to the mtl package as we don't depend on it
167Ian Lynagh <igloo@earth.li>**20071126170631]
168[Escape some special characters in haddock docs
169Ian Lynagh <igloo@earth.li>**20071126163443]
170[FIX BUILD: maybeUpdateFile: ignore failures when removing the target
171Simon Marlow <simonmar@microsoft.com>**20071123092219]
172[FIX #1753
173Simon Marlow <simonmar@microsoft.com>**20071122094207
174 hClose should close the Handle and unlock the file even if calling
175 close() fails for some reason.
176]
177[remove lockFile.h from install-includes
178Simon Marlow <simonmar@microsoft.com>**20071121102248]
179[oops, we forgot to export traceShow
180Simon Marlow <simonmar@microsoft.com>**20071121094300]
181[Fix compilation with GHC 6.2.x
182Simon Marlow <simonmar@microsoft.com>**20071121084341]
183[Move file locking into the RTS, fixing #629, #1109
184Simon Marlow <simonmar@microsoft.com>**20071120121053
185 File locking (of the Haskell 98 variety) was previously done using a
186 static table with linear search, which had two problems: the array had
187 a fixed size and was sometimes too small (#1109), and performance of
188 lockFile/unlockFile was suboptimal due to the linear search.
189 Also the algorithm failed to count readers as required by Haskell 98
190 (#629).
191 
192 Now it's done using a hash table (provided by the RTS).  Furthermore I
193 avoided the extra fstat() for every open file by passing the dev_t and
194 ino_t into lockFile.  This and the improvements to the locking
195 algorithm result in a healthy 20% or so performance increase for
196 opening/closing files (see openFile008 test).
197]
198[Only overwrite GHC/Prim.hs and GHC/Primopwrappers.hs if they change
199Simon Marlow <simonmar@microsoft.com>**20071120102042
200 This avoids make doing unnecessary work after 'setup makefile'.
201]
202[fix comment
203Simon Marlow <simonmar@microsoft.com>**20071116091227]
204[Fix ` characters in elem's haddock docs
205Ian Lynagh <igloo@earth.li>**20071110173052]
206[Filter out GHC.Prim also for the Haddock step
207David Waern <david.waern@gmail.com>**20071109000806
208 Please merge to the GHC 6.8.2 branch
209]
210[Add module of special magic GHC desugaring helper functions
211Simon Marlow <simonmar@microsoft.com>**20071102160054
212 Currently containing only one such helper: (>>>) for arrow desugaring
213]
214[add Control.Category to the nhc98 build
215Malcolm.Wallace@cs.york.ac.uk**20071030120459]
216[fix nhc98 build: need a qualified Prelude import
217Malcolm.Wallace@cs.york.ac.uk**20071030120410]
218[Fix performance regression: re-instate -funbox-strict-fields
219Simon Marlow <simonmar@microsoft.com>**20071029150730
220 Yikes!  While investigating the increase in code size with GHC 6.8
221 relative to 6.6, I noticed that in the transition to Cabal for the
222 libraries we lost -funbox-strict-fields, which is more or less
223 depended on by the IO library for performance.  I'm astonished that we
224 didn't notice this earlier!
225 
226 To reduce the chances of this happening again, I put
227 -funbox-strict-fields in the OPTIONS_GHC pragma of the modules that
228 need it.  {-# UNPACK #-} pragmas would be better, though.
229]
230[FIX BUILD: Haddock 1.x fails to parse (Prelude..)
231Simon Marlow <simonmar@microsoft.com>**20071029131921]
232[new Control.Category, ghc ticket #1773
233Ashley Yakeley <ashley@semantic.org>**20071029022526]
234[new Control.Compositor module
235Ashley Yakeley <ashley@semantic.org>**20071013074851
236 
237 The Compositor class is a superclass of Arrow.
238]
239[Fix doc building with Haddock 0.9
240Simon Marlow <simonmar@microsoft.com>**20071024090947
241 I was using a recent build here, which is more tolerant.
242]
243[FIX #1258: document that openTempFile is secure(ish)
244Simon Marlow <simonmar@microsoft.com>**20071023130928
245 Also change the mode from 0666 to 0600, which seems like a more
246 sensible value and matches what C's mkstemp() does.
247]
248[Clean up .cabal file a bit
249Duncan Coutts <duncan@haskell.org>**20071022132708
250 specify build-type and cabal-version >= 1.2
251 put extra-tmp-files in the right place
252 use os(windows) rather than os(mingw32)
253]
254[base in 6.8 and head branch should be version 3.0
255Don Stewart <dons@galois.com>**20071007150408]
256[FIX #1652: openTempFile should accept an empty string for the directory
257Simon Marlow <simonmar@microsoft.com>**20071018122345]
258[clean up duplicate code
259Simon Marlow <simonmar@microsoft.com>**20071017141311]
260[expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733)
261Simon Marlow <simonmar@microsoft.com>**20071009132042]
262[typo
263Simon Marlow <simonmar@microsoft.com>**20070917130703]
264[put extra-tmp-files field in the right place
265Simon Marlow <simonmar@microsoft.com>**20070914140812]
266[Add more entries to boring file
267Ian Lynagh <igloo@earth.li>**20070913210500]
268[Add a boring file
269Ian Lynagh <igloo@earth.li>**20070913204641]
270[TAG 2007-09-13
271Ian Lynagh <igloo@earth.li>**20070913215720]
272Patch bundle hash:
2734e19d96dccd202b779d52ad8f4154b470598b1d5