av_ 2017-01-30 20:53:19
hello everybody -- I'm reading up on IORef and found this in the docs: "Extending the atomicity to multiple IORefs is problematic" -- can anyone explain why that is, or point me to some literature?
ongy 2017-01-30 20:54:45
atomic stuff is interesting for multithreaded applications. It's roughly "how the world sees things"
av_ 2017-01-30 20:56:11
ongy: OK, I know that, but why does it make a difference whether I have a single IORef or more than one?
Lokathor 2017-01-30 20:56:31
seems you can't build gtk at the moment on windows :/
ongy 2017-01-30 20:56:33
so if you had 2 bins of something represented as IORef Int (for how many are in there) and you want to move one piece from x to y you could do "do { modifyIORef x (+1); modifyIORef y (subtract 1) }. But any observer from the outside can see the state between the 2 operations
Lokathor 2017-01-30 20:56:40
cairo is all sorts of upset
Lokathor 2017-01-30 20:58:06
http://lpaste.net/351817
Lokathor 2017-01-30 20:58:56
ongy, can IORef have data races?
av_ 2017-01-30 20:58:58
ongy: ah, ok! So it's tricky to extend atomicity to operations involving multiple IORefs -- I think that would be a more appropriate statement, I find the docs slightly confusing
geekosaur 2017-01-30 20:59:04
av_, it doesn't lock, it just inserts a write barrier. if you need to modify more than one thing "atomically", you need locking or synchronization. this is not provided automatically because how would it know what to synchronize? so you use an MVar for synchronization/locking, or (better) a TVar
av_ 2017-01-30 20:59:50
the other sentence in the docs is even more confusing: "If you only have one IORef, then using atomicModifyIORef to access and modify it will prevent race conditions."
Lokathor 2017-01-30 21:00:29
av_, between a read and a write, someone else might perform a write, is what's being said there
av_ 2017-01-30 21:00:37
as I understand it, even if I have multiple IORefs, using atomicModifyIORef to modify one of them at the time prevents race conditions, right?
ongy 2017-01-30 21:00:55
av_: low level synchronication primitives aren't encouraged in the Haskell world, so MVar/TVar are prefered
av_ 2017-01-30 21:01:03
assuming I don't care about the others...
av_ 2017-01-30 21:01:43
ongy: sure, I just want to understand why the docs say what they say, from what I'm told now it looks like the docs are misleading
cocreature 2017-01-30 21:01:53
av_: yeah you are right. the docs refer to atomic operations that access multiple IORefs
av_ 2017-01-30 21:02:13
cocreature: thanks, it all makes sense now
ongy 2017-01-30 21:04:24
also, memory model makes things even more fun
av_ 2017-01-30 21:04:47
ongy: yes, so I'm told...
Lokathor 2017-01-30 21:05:05
and hsqml also doesn't seem to actually build with stack
av_ 2017-01-30 21:05:09
thanks everyone
Lokathor 2017-01-30 21:05:10
not lucky today i guess
geekosaur 2017-01-30 21:06:05
Lokathor, you have multiple versions of the Cabal library installed and they're getting mismatched. probably nothing (or very little) will build correctly in that config
Lokathor 2017-01-30 21:06:29
this is all stack's fault!
Lokathor 2017-01-30 21:06:34
also, many packages are building just fine
Lokathor 2017-01-30 21:06:55
just not the actual GUI toolkits that I want
geekosaur 2017-01-30 21:07:27
urgh, gtk2hs, right, this has special build requirements because it does Evil Things(tm) in its Setup.hs
Lokathor 2017-01-30 21:07:31
http://lpaste.net/351818 unless stack is lying that most of the dependencies built
geekosaur 2017-01-30 21:07:44
iirc there is a ticket open about dealing with it
Lokathor 2017-01-30 21:07:52
oh well
Lokathor 2017-01-30 21:38:59
ooh
Lokathor 2017-01-30 21:39:07
seems FLTK might work out
Lokathor 2017-01-30 21:39:47
does enough type magic to take longer than rust to compile though
