
How to sleep a million years (2013) - bemmu
https://idea.popcount.org/2013-07-19-how-to-sleep-a-million-years/
======
abetusk
An example usage from the article:

    
    
        $ time sleep 12
        real    0m12.003s
    
        $ time ./fluxcapacitor -- sleep 12
        real    0m0.057s
    

In the author's words:

    
    
        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.
    

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.

~~~
thaumaturgy
Yeah, this is amazing. It allows for a whole different aspect of
troubleshooting (or maybe even fuzzing?). What happens if two different pieces
of software have to communicate but can't agree on the time? Is there an
annoying caching bug that normally only gets triggered every few days?

~~~
majke
(author here) That's the intention! Protocol development, protocol testing.
Think - leap seconds. While we don't support having different timer for each
process yet, this is easy to imagine.

Also - this is somewhat similar to golang race detector in spirit - looking
for explicit synchronizations.

The general idea is that you should be able to run multiple processes within
the thing, and that they should be able to just talk to each other freely.

There are a number of "protocol simulators" out there, but I always found them
academic. I wanted to build a tool that will allow me run and test and do code
coverage of my code, without having to wait forever for timeouts and timers to
kick in to test rare branches.

------
solipsism
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.

~~~
hughes
Sounds like a good way to discover those timing-dependent scenarios before
they happen in production ;)

------
amelius
> 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.

------
sillysaurus3
I tried patching for macOS then quickly gave up.

Here's a patch to get you started:
[https://gist.github.com/anonymous/bab9c0fcafd9a03acfaa89741f...](https://gist.github.com/anonymous/bab9c0fcafd9a03acfaa89741f26eb36)

I don't know whether it even makes sense to try porting this to macOS, but
good luck.

~~~
saagarjha
You may want to take a look at task_for_pid and other Mach APIs–ptrace is
crippled on macOS.

------
dibujante
Finally, sleepsort is practical!

~~~
v_lisivka
Sleepsort is fastest sorting algo in some cases already. It complexity:
O(max(input)+n). It bad algo for CPU, of course, but should be OK for massive
parallel architecture or a FPGA.

------
jwilk
> Unfortunately my operating system (bash?) can't express dates after the year
> 2550

Can anyone explain what happened here?

~~~
brazzy
Very good question - nothing near that date shows up on this very exhaustive
list:
[http://skeena.net/kb/big%20list%20of%20critical%20dates.html](http://skeena.net/kb/big%20list%20of%20critical%20dates.html)

------
imoverclocked
This may have just made my production cluster WAY faster! ;)

------
subpar
Hey, there's a great song about this!
[https://www.youtube.com/watch?v=uSgQiltRqNI](https://www.youtube.com/watch?v=uSgQiltRqNI)

------
loeg
Very cool. Unfortunately, it doesn't seem like it captures filesystem effects
like 'mtime' or other ways the real time can leak out implicitly.

------
Tepix
This is fantastic, I was working on some tests for a scheduler, I can speed up
running these tests using fluxcapacitor!

