_queuesWithWork can go negative.
Consider the following scenario
there are 2 queues first one has work and
consumer is active.
1. producer adds work to queue 1 and sees it needs
to update _queuesWithWork but is preempted
2. consumer consumes work from queue 0 and
decrements _queuesWithWork to 0
3. consumer continues consuming and consumes all
work from queue 1
4. consumer decrements _queuesWithWork to -1
5. only now producer updates _queuesWithWork to 0
It could be also solved by removeWork returning new value
and then consumer stopping consumption if it is 0.
This is in preparation with a deeper refactor of reading from Go
in general. The big difference that we have now which we did not
have before is that we now have CRCs for every single page.
The FUSE driver, up to now, had no way to know when the user had
"explicitly" closed a file. Instead it linked the TernFS file on
flush, which could cause nasty situation. The classic example
is a fork causing the FD to a TernFS file being present in the forked
process, and then the process dying causing a spurious flush.
This commit adds a way to detect when a flush is due to a close(),
which allows us to link the file only in the cases where that happened,
which is a much better heuristic and close to what we do in the kernel
module.
This commit also contains various other improvements to make all tests
pass under FUSE. The big remaining item is changing how files are read
(they're currently read all upfront and then kept in memory).
Unfortunately Lemire's wyhash code was licensed as Apache, we'd rather
have something compatible with GPLv2. This probably a more appropriate
choice anyway.
Things not done because probably disruptive:
* kmod filesystem string
* sysctl/debugfs/trace
* metrics names
* xmon instance names
Some of these might be renamed too, but starting with a relatively
safe set.
Miroslav Crnic