An example usage from the article:
In the author's words:
$ time sleep 12 real 0m12.003s $ time ./fluxcapacitor -- sleep 12 real 0m0.057s
It seems that this library might be useful to anyone needing to test communication protocols by helping tickle those edge cases that happen with timing.
Fluxcapacitor is really good at speeding up client/server or protocol tests. Actually fluxcapacitor was originally created to speed up the sockjs-protocol test suite. It wasn't possible to mock up a time library - we needed to run the tests against any sockjs http server, whether it's in erlang, node.js or python. It turns out the only way to run timeout-related tests in a reasonable time is to use fluxcapacitor. You might ask how fluxcapacitor works. In short - it uses ptrace to catch syscalls like clock_gettime or gettimeofday and overwrite the kernel response with a fake time. Additionally it short-circuits syscalls that can block for a timeout like select or poll. For technical details see the README.
> You might ask how fluxcapacitor works. In short - it uses ptrace to catch syscalls like clock_gettime or gettimeofday and overwrite the kernel response with a fake time.
In Linux, ptrace is not re-entrant. This means you can't use fluxcapacitor on itself, or any other program that uses ptrace, e.g. a debugger.
I tried patching for macOS then quickly gave up.
Here's a patch to get you started: https://gist.github.com/anonymous/bab9c0fcafd9a03acfaa89741f...
I don't know whether it even makes sense to try porting this to macOS, but good luck.
Very cool. Unfortunately, it doesn't seem like it captures filesystem effects like 'mtime' or other ways the real time can leak out implicitly.
This may have just made my production cluster WAY faster! ;)
Hey, there's a great song about this! https://www.youtube.com/watch?v=uSgQiltRqNI
Finally, sleepsort is practical!
This is cool but it should be used with caution. The time your thread spends sleeping may be reduced to nothing, but the time it spends working won't be. This could lead to all kinds of scenarios (timeouts, deadlocks, etc) that are only theoretically possible in realtime. It may or may not be useful to encounter these cases.
Edit: also worth mentioning that a good way of doing this kind of testing when you have full control of the code is by abstracting access to time operations to go through an interface and injecting mock/fake time objects.
But you don't always have access to the code, so I think this tool is very useful.