Fix a bunch of bugs and infelicities by treeowl · Pull Request #9 · ygale/strict-concurrency

treeowl · 2019-01-15T22:13:00Z

Fixes #2
Fixes #3
Fixes #4
Fixes #5
Fixes #6
Fixes #8

treeowl · 2019-01-15T23:30:11Z

@crockeea, please have a look at this.

Fixes ygale#2, ygale#3, ygale#4, ygale#5, ygale#6, and ygale#8

crockeea

Still missing modifyMVarMasked_, modifyMVarMasked, and mkWeakMVar.

Much improved overall!

crockeea · 2019-01-16T00:27:05Z

-    case putMVar# mvar# x s# of
-        s2# -> (# s2#, () #)
-#endif
+putMVar !mv !x = rnf x `seq` MV.putMVar mv x


Suggested change

putMVar !mv !x = rnf x `seq` MV.putMVar mv x

putMVar !mv x = rnf x `seq` MV.putMVar mv x

Gratuitous bang?

That's needed to preserve the original behavior if rnf doesn't actually force anything.

instance NFData Foo where rnf _ = ()

What we can do is change that to putMVar !mv x = force x `seq` MV.putMVar mv x. I guess that's better.

I'm afraid that subtlety is lost on me. force x is equivalent to rnf x `seq` x, and that's materially different from rnf x? I'll take your word for it.

Define

data Foo instance NFData Foo where rnf _ = () f, g :: Foo -> () f x = force x `seq` () g x = rnf x `seq` ()

Then f undefined = undefined, but g undefined = ().

Whether this is the "right" decision is somewhat unclear to me, but it matches the previous behavior.

Thanks for that example. The documentation for rnf says:

rnf should reduce its argument to normal form (that is, fully evaluate all sub-components), and then return '()'.

so doesn't your instance violate that? At any rate, this is indeed a pathological corner case, and I have no opinion.

There are special circumstances when you might conceivably want rnf to do nothing, as a generic way to force the spine of a data structure but not its leaves. Do we want to worry about that?

crockeea · 2019-01-16T00:34:29Z

 -}
 swapMVar :: NFData a => MVar a -> a -> IO a
-swapMVar mvar new = mask $ \_ -> do
+swapMVar !mvar new = seq (force new) $ mask $ \_ -> do


Shouldn't the local putMVar suffice, like the original version?

I believe we want to force before we take the MVar. That way we don't hold the MVar any longer than necessary. We also avoid problems if the forcing throws an exception. Once we've forced manually, we don't want to do it again implicitly, because that would be a waste of time.

crockeea · 2019-01-16T00:39:18Z

-    a' <- Exception.catch (unmask (io a))
-            (\(e :: SomeException) -> do putMVar m a; throw e)
-    putMVar m a'
+modifyMVar_ m io = MV.modifyMVar_ m $ io >=> \p -> force p `seq` return p


Bang on m?

Suggested change

modifyMVar_ m io = MV.modifyMVar_ m $ io >=> \p -> force p `seq` return p

modifyMVar_ !m io = MV.modifyMVar_ m $ io >=> \p -> force p `seq` return p

No need. MV.modifyMVar_ does that for us.

crockeea · 2019-01-16T00:39:38Z

-    putMVar m a'
-    return b
-
+modifyMVar m io = MV.modifyMVar m $ io >=> \pq -> force (fst pq) `seq` return pq


Bang on m?

Suggested change

modifyMVar m io = MV.modifyMVar m $ io >=> \pq -> force (fst pq) `seq` return pq

modifyMVar !m io = MV.modifyMVar m $ io >=> \pq -> force (fst pq) `seq` return pq

Again, no need.

crockeea · 2019-01-16T00:40:29Z

-    case tryPutMVar# mvar# x s# of
-        (# s, 0# #) -> (# s, False #)
-        (# s, _  #) -> (# s, True #)
+tryPutMVar !mv !x = rnf x `seq` MV.tryPutMVar mv x


Gratuitous bang?

Suggested change

tryPutMVar !mv !x = rnf x `seq` MV.tryPutMVar mv x

tryPutMVar !mv x = rnf x `seq` MV.tryPutMVar mv x

Again, needed if we want to force to WHNF if rnf does nothing.

treeowl · 2019-01-16T00:58:10Z

Still missing modifyMVarMasked_, modifyMVarMasked, and mkWeakMVar.

Yes, I noticed that too... I suppose I could just shove those in here too.

treeowl · 2019-01-17T17:13:04Z

@ygale, have you had a chance to look at this yet?

treeowl · 2019-01-17T17:20:13Z

+tryReadMVar :: MVar a -> IO (Maybe a)
+-- This is a best-effort compatibility shim for really old GHC versions.
+-- It's not really what you'd call *right*.
+tryReadMVar !m = uninterruptibleMask $ \_ -> do


Actually, mask should be enough, since nothing in here is interruptible. An earlier draft used putMVar. I'm not sure which version makes the least nonsense. But ultimately, it doesn't really matter much, since this is a half-broken shim. (readMVar itself should be considered half-broken for earlier base versions, since it used to be non-atomic and potentially disruptive.)

ygale · 2019-01-19T22:02:15Z

@ygale, have you had a chance to look at this yet?

Yes, great work, thanks! As I hope you saw, I put out a call on the libraries list in case anyone has something to add. I'll give that a few days to percolate. Unless some serious question comes to light, I'll merge in about a week.

ygale · 2019-01-26T20:25:35Z

@treeowl What am I supposed to merge? Just this PR, or just #10, or both?

ygale · 2019-01-26T20:44:04Z

@treeowl For whatever should be merged:

Please pull .travis.yml from master to enable also GHC 8.6.2 and 8.6.3 builds
Please bump the package version appropriately.
Thanks!

tchoutri · 2022-01-04T22:18:31Z

@treeowl @ygale Any news regarding this PR? :)

treeowl · 2022-01-04T22:20:43Z

I've quite forgotten about it.

ygale · 2022-01-08T20:10:15Z

@treeowl I had also forgotten. I see that at the time I was ready to merge - except it wasn't clear whether I'm supposed to merge just this, just #10 , or both. You asked @simonmar to give a look at #10 and he seemed to be fine with it.

So @tchoutri thanks for the ping! I am ready to merge as soon as someone tells me what to merge - this, #10, or both.

We now need to move from travis CI to github actions - i'll do that now.

treeowl · 2022-01-08T20:23:43Z

I think #10 is good to go. With this one, there's still a question in my mind about whether you want to force values whose rnf does nothing.

Co-authored-by: ygale <gale@sefer.org>

ygale · 2022-01-08T23:01:20Z

OK thanks. My opinion is - don't worry about do-nothing rnf. The purpose of the NFData class is to apply strictness down to the bottom. If someone wants to do something else, they can create a different class.

But I'm not a decision maker here. I'm just trying to help out by providing a home for an important library that became an orphan at some point. So I'll defer to you. I'll merge #10 . Let me know if and when I should merge this PR.

ygale · 2022-01-09T00:07:28Z

@treeowl If you do take my dubious advice and not worry about do-nothing rnf, then please do make sure to mention that behavior prominently in the haddocks. Especially if this is a change from previous behavior. I believe that will make a difference in the PVP version number for the upcoming release.

Before release I am waiting for the final decision about this PR. Or a decision to push it off for now. In any case, let's not fall back into a collective stupor again. Please ping me and wake me up within the next few days! Thanks.

Remove conditional import of `tryReadMVar` for re-export in non-ancient versions. Instead, we are making the export itself conditional, only for the ancient versions where it is needed. That is a slightly less invasive change.

treeowl · 2022-01-09T01:06:15Z

I will review to see if I've changed the strictness in do-nothing rnf. If so, I'll probably undo that for PVP reasons and we can discuss it further later.

ygale · 2023-12-30T22:05:43Z

@treeowl hmm this got stuck again. Do I merge this PR as is? Are we making further changes? Are we abandoning it altogether? Please let's decide and finally get this off the table. Thanks!

treeowl force-pushed the lotsa-fixes branch 5 times, most recently from a449ac4 to 6b7fbaf Compare January 15, 2019 23:22

treeowl force-pushed the lotsa-fixes branch from 6b7fbaf to 5d6cd97 Compare January 15, 2019 23:33

Fix a bunch of bugs and infelicities

64deaaa

Fixes ygale#2, ygale#3, ygale#4, ygale#5, ygale#6, and ygale#8

treeowl force-pushed the lotsa-fixes branch from 5d6cd97 to 64deaaa Compare January 16, 2019 00:27

crockeea reviewed Jan 16, 2019

View reviewed changes

crockeea approved these changes Jan 16, 2019

View reviewed changes

treeowl commented Jan 17, 2019

View reviewed changes

ygale reviewed Jan 8, 2022

View reviewed changes

Comment thread Control/Concurrent/MVar/Strict.hs

Update Control/Concurrent/MVar/Strict.hs

d48056c

Co-authored-by: ygale <gale@sefer.org>

ygale mentioned this pull request Jan 8, 2022

Monadic #10

Closed

ygale reviewed Jan 9, 2022

View reviewed changes

Comment thread Control/Concurrent/MVar/Strict.hs Outdated

Update Control/Concurrent/MVar/Strict.hs

e70503c

Remove conditional import of `tryReadMVar` for re-export in non-ancient versions. Instead, we are making the export itself conditional, only for the ancient versions where it is needed. That is a slightly less invasive change.

	putMVar !mv !x = rnf x `seq` MV.putMVar mv x
	putMVar !mv x = rnf x `seq` MV.putMVar mv x

	modifyMVar_ m io = MV.modifyMVar_ m $ io >=> \p -> force p `seq` return p
	modifyMVar_ !m io = MV.modifyMVar_ m $ io >=> \p -> force p `seq` return p

	modifyMVar m io = MV.modifyMVar m $ io >=> \pq -> force (fst pq) `seq` return pq
	modifyMVar !m io = MV.modifyMVar m $ io >=> \pq -> force (fst pq) `seq` return pq

	tryPutMVar !mv !x = rnf x `seq` MV.tryPutMVar mv x
	tryPutMVar !mv x = rnf x `seq` MV.tryPutMVar mv x

Conversation

treeowl commented Jan 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

treeowl commented Jan 15, 2019

Uh oh!

crockeea left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

treeowl Jan 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crockeea Jan 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

treeowl Jan 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

treeowl commented Jan 16, 2019

Uh oh!

treeowl commented Jan 17, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ygale commented Jan 19, 2019

Uh oh!

ygale commented Jan 26, 2019

Uh oh!

ygale commented Jan 26, 2019

Uh oh!

tchoutri commented Jan 4, 2022

Uh oh!

treeowl commented Jan 4, 2022

Uh oh!

ygale commented Jan 8, 2022

Uh oh!

Uh oh!

treeowl commented Jan 8, 2022

Uh oh!

ygale commented Jan 8, 2022

Uh oh!

ygale commented Jan 9, 2022

Uh oh!

Uh oh!

treeowl commented Jan 9, 2022

Uh oh!

ygale commented Dec 30, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

treeowl commented Jan 15, 2019 •

edited

Loading

treeowl Jan 16, 2019 •

edited

Loading

crockeea Jan 16, 2019 •

edited

Loading

treeowl Jan 16, 2019 •

edited

Loading