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