-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excessive handler duplication when running in serial #28
Comments
You're right that duplication should only be the result of an addHandler/put race, but it's actually very difficult to write purely sequential LVish code, because every callback executes in its own logical thread (even if they are all running on the same OS-level thread). I can try to help track this down if you can point me to the code you're running here. |
If you take a peek at that simple reproducer it is not purely sequential, but it does register the handler before it ever does any puts, so there should be no races. On my machine I see two copies of both of those handlers, resulting in this test failure:
I'm coming back to this now because I'm currently debugging the "ParFoldable" instance for SLMap, which is suffering from duplication related errors. (Probably unrelated though...) Heh, this is a good testing methodology though to make sure things are really idempotent! |
Interestingly, the excessive duplication is only on the SLMap version (see issue #28).
If all the prereqs are installed, the simplest way to reproduce this failure (as of rev 1e2d1c3) is:
You should see the failing test there. |
global thresh function runs sequential on the same thread as addHandler. In the next commit the interface of addHandler will change to reflect this. Also, add a bunch of debugging related to the handler duplication test.
and instead just be a Par action run on the same thread as addHandler. All 57 enabled tests pass on one thread, but I'm seeing big problems on multiple threads (~8/57 test failures).
In the course of debugging some stuff in GHCI, I'm seeing consistent double-execution of EVERY handler on my SLSet:
My (incorrect?) understanding was that handler duplication should only happen on the addHandler / put data-race, and the sequential version should have NO data-races right?
This is not a correctness problem, because of idempotency, but it is weird and possibly inefficient.
Oh, one more thing, like #27, this seems to only be with
SLSet
, not withPureSet
.@aturon, what do you think?
The text was updated successfully, but these errors were encountered: