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

Monkey patch two dependencies to use /dev/unrandom over /dev/random #23

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@kaoru

kaoru commented May 31, 2015

Proof of concept... I don't recommend or expect you to actually merge this! :-)


This makes the tests 11-encrypt.t and 13-keygen.t run consistently
quickly, whereas before they were intermittently much slower.

Before:

$ for i in $(seq 1 10) ; do prove -b t/11-encrypt.t 2>&1 | grep wallclock ; done
Files=1, Tests=36, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.67 cusr 0.01 csys = 0.71 CPU)
Files=1, Tests=36, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.64 cusr 0.02 csys = 0.70 CPU)
Files=1, Tests=36, 80 wallclock secs ( 0.03 usr 0.00 sys + 0.66 cusr 0.01 csys = 0.70 CPU)
Files=1, Tests=36, 87 wallclock secs ( 0.04 usr 0.00 sys + 0.55 cusr 0.00 csys = 0.59 CPU)
Files=1, Tests=36, 67 wallclock secs ( 0.03 usr 0.00 sys + 0.58 cusr 0.00 csys = 0.61 CPU)
Files=1, Tests=36, 89 wallclock secs ( 0.03 usr 0.01 sys + 0.49 cusr 0.02 csys = 0.55 CPU)
Files=1, Tests=36, 83 wallclock secs ( 0.03 usr 0.01 sys + 0.65 cusr 0.02 csys = 0.71 CPU)
Files=1, Tests=36, 80 wallclock secs ( 0.04 usr 0.01 sys + 0.60 cusr 0.01 csys = 0.66 CPU)
Files=1, Tests=36, 34 wallclock secs ( 0.04 usr 0.00 sys + 0.62 cusr 0.03 csys = 0.69 CPU)
Files=1, Tests=36, 32 wallclock secs ( 0.02 usr 0.00 sys + 0.54 cusr 0.01 csys = 0.57 CPU)

After:

$ for i in $(seq 1 10) ; do prove -b t/11-encrypt.t 2>&1 | grep wallclock ; done
Files=1, Tests=36, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.43 cusr 0.01 csys = 0.46 CPU)
Files=1, Tests=36, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.41 cusr 0.00 csys = 0.43 CPU)
Files=1, Tests=36, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.40 cusr 0.01 csys = 0.43 CPU)
Files=1, Tests=36, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.40 cusr 0.00 csys = 0.43 CPU)
Files=1, Tests=36, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.42 cusr 0.02 csys = 0.47 CPU)
Files=1, Tests=36, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.40 cusr 0.01 csys = 0.44 CPU)
Files=1, Tests=36, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.40 cusr 0.00 csys = 0.43 CPU)
Files=1, Tests=36, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.39 cusr 0.01 csys = 0.43 CPU)
Files=1, Tests=36, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.41 cusr 0.01 csys = 0.45 CPU)
Files=1, Tests=36, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.41 cusr 0.00 csys = 0.44 CPU)

Monkey patch two dependencies to use /dev/unrandom over /dev/random
This makes the tests 11-encrypt.t and 13-keygen.t run consistently
quickly, whereas before they were intermittently much slower.

Before:

$ for i in $(seq 1 10) ; do prove -b t/11-encrypt.t 2>&1 | grep wallclock ; done
Files=1, Tests=36,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.67 cusr 0.01 csys =  0.71 CPU)
Files=1, Tests=36,  1 wallclock secs ( 0.04 usr  0.00 sys +  0.64 cusr 0.02 csys =  0.70 CPU)
Files=1, Tests=36, 80 wallclock secs ( 0.03 usr  0.00 sys +  0.66 cusr 0.01 csys =  0.70 CPU)
Files=1, Tests=36, 87 wallclock secs ( 0.04 usr  0.00 sys +  0.55 cusr 0.00 csys =  0.59 CPU)
Files=1, Tests=36, 67 wallclock secs ( 0.03 usr  0.00 sys +  0.58 cusr 0.00 csys =  0.61 CPU)
Files=1, Tests=36, 89 wallclock secs ( 0.03 usr  0.01 sys +  0.49 cusr 0.02 csys =  0.55 CPU)
Files=1, Tests=36, 83 wallclock secs ( 0.03 usr  0.01 sys +  0.65 cusr 0.02 csys =  0.71 CPU)
Files=1, Tests=36, 80 wallclock secs ( 0.04 usr  0.01 sys +  0.60 cusr 0.01 csys =  0.66 CPU)
Files=1, Tests=36, 34 wallclock secs ( 0.04 usr  0.00 sys +  0.62 cusr 0.03 csys =  0.69 CPU)
Files=1, Tests=36, 32 wallclock secs ( 0.02 usr  0.00 sys +  0.54 cusr 0.01 csys =  0.57 CPU)

After:

$ for i in $(seq 1 10) ; do prove -b t/11-encrypt.t 2>&1 | grep wallclock ; done
Files=1, Tests=36,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.43 cusr 0.01 csys =  0.46 CPU)
Files=1, Tests=36,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.41 cusr 0.00 csys =  0.43 CPU)
Files=1, Tests=36,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.40 cusr 0.01 csys =  0.43 CPU)
Files=1, Tests=36,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.40 cusr 0.00 csys =  0.43 CPU)
Files=1, Tests=36,  1 wallclock secs ( 0.03 usr  0.00 sys +  0.42 cusr 0.02 csys =  0.47 CPU)
Files=1, Tests=36,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.40 cusr 0.01 csys =  0.44 CPU)
Files=1, Tests=36,  1 wallclock secs ( 0.03 usr  0.00 sys +  0.40 cusr 0.00 csys =  0.43 CPU)
Files=1, Tests=36,  0 wallclock secs ( 0.02 usr  0.01 sys +  0.39 cusr 0.01 csys =  0.43 CPU)
Files=1, Tests=36,  1 wallclock secs ( 0.02 usr  0.01 sys +  0.41 cusr 0.01 csys =  0.45 CPU)
Files=1, Tests=36,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.41 cusr 0.00 csys =  0.44 CPU)
@rfdrake

This comment has been minimized.

Show comment
Hide comment
@rfdrake

rfdrake Sep 11, 2015

I'm not a developer of the project, but if you're mainly concerned with test cases then I would monkey patch there instead of in the modules themselves. Alternatively, you could write a module that patched when it was loaded to override the other modules, then run something like:

prove -lv -MMonkey::URandom t/test.t

The real problem is that these kinds of patches are unsafe and hard to maintain through upstream changes. It would be nice if Crypt::Random::Util would let you set the order, or if the other module would use a shared "our" variable as the source for the random file. Then you could just patch that line instead of rewriting the whole function.

rfdrake commented Sep 11, 2015

I'm not a developer of the project, but if you're mainly concerned with test cases then I would monkey patch there instead of in the modules themselves. Alternatively, you could write a module that patched when it was loaded to override the other modules, then run something like:

prove -lv -MMonkey::URandom t/test.t

The real problem is that these kinds of patches are unsafe and hard to maintain through upstream changes. It would be nice if Crypt::Random::Util would let you set the order, or if the other module would use a shared "our" variable as the source for the random file. Then you could just patch that line instead of rewriting the whole function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment