Excessive handler duplication when running in serial

[rrnewton]

In the course of debugging some stuff in GHCI, I'm seeing consistent double-execution of EVERY handler on my SLSet:

*Main> mem01
makeMemo, about to insert result: ("10","11")
makeMemo, about to insert result: ("100","101")
makeMemo, about to insert result: ("10","11")
makeMemo, about to insert result: ("100","101")

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 with PureSet.

@aturon, what do you think?

[aturon]

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.

[rrnewton]

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:

ERROR: LVarSpecificExn "EXCEPTION in runPar(ThreadId 5): HUnitFailure \"Should be no duplication in this case\\nexpected: 2\\n but got: 4\""

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!

[rrnewton]

If all the prereqs are installed, the simplest way to reproduce this failure (as of rev 1e2d1c3) is:

cd lvish/tests
make main
./Main_wfailing.exe -t handlr

You should see the failing test there.