[Haskell-cafe] Re: threads + IORefs = Segmentation fault?
David Roundy <[EMAIL PROTECTED]> wrote: > {-# NOINLINE _progressData #-} > _progressData :: IORef (Map String ProgressData) > _progressData = unsafePerformIO $ newIORef empty > > updateProgressData :: String > -> (ProgressData -> ProgressData) > -> IO () > updateProgressData k f = when (progressMode) $ modifyIORef > _progressData (adjust f k) > The question I'm asking myself is why you would want to modify a reference to an always empty Map, which would be the case if unsafePerformIO performs its action every time. If it doesnt' (and experience suggest that it doesn't, as does the faithful usage of {-# NOINLINE #-}, BUT YOU'LL NEVER, EVER, KNOW), I'm wondering why you don't create the IORef in beginTedious and pass it around. Possibly even with an implicit parameter. And, yes, without multiple writing threads locking is unnecessary, and mostly even with multiple writing threads, if they don't read, too. /me mandates the renaming of unsafePerformIO to iReallyReallyThoughtReallyHardAboutThisAndThereReallyIsNoDifferentWayThanToUseThisDreadedUnsafePerformIO. OTOH, I have no idea what causes the segfault. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: threads + IORefs = Segmentation fault?
David Roundy wrote: I'm working on some new progress-reporting code for darcs, and am getting segmentation faults! :( The code uses threads + an IORef global variable to do this (with lots of unsafePerformIO). So my question for the gurus who know more about this than I do: is this safe? I thought it would be, because only one thread ever modifies the IORef, and the others only read it. I don't really care if they read a correct value, as long as they don't segfault. The code (to summarize) looks like: {-# NOINLINE _progressData #-} _progressData :: IORef (Map String ProgressData) _progressData = unsafePerformIO $ newIORef empty updateProgressData :: String -> (ProgressData -> ProgressData) -> IO () updateProgressData k f = when (progressMode) $ modifyIORef _progressData (adjust f k) setProgressData :: String -> ProgressData -> IO () setProgressData k p = when (progressMode) $ modifyIORef _progressData (insert k p) getProgressData :: String -> IO (Maybe ProgressData) getProgressData k = if progressMode then lookup k `fmap` readIORef _progressData else return Nothing (I'm a bit behind with haskell-cafe, sorry for not seeing this sooner...) Yes, that should all be fine, because the IORef is only modified from one thread, and read from the other(s). If you were modifying the IORef from more than one thread you would need to use atomicallyModifyIORef, or MVars. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: threads + IORefs = Segmentation fault?
David Roundy wrote: Yes, that should all be fine, because the IORef is only modified from one thread, and read from the other(s). If you were modifying the IORef from more than one thread you would need to use atomicallyModifyIORef, or MVars. If I did modify the IORef from more than one thread (e.g. if a bug were introduced), would this cause any trouble other than occasional missed updates or reads of wrong data? It shouldn't, no. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: threads + IORefs = Segmentation fault?
On Fri, Feb 08, 2008 at 10:46:25AM +, Simon Marlow wrote: > (I'm a bit behind with haskell-cafe, sorry for not seeing this sooner...) No problem! > Yes, that should all be fine, because the IORef is only modified from one > thread, and read from the other(s). If you were modifying the IORef from > more than one thread you would need to use atomicallyModifyIORef, or MVars. If I did modify the IORef from more than one thread (e.g. if a bug were introduced), would this cause any trouble other than occasional missed updates or reads of wrong data? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe