[erlang-questions] Changing scheduler behaviour to make tests less deterministic

[Thomas Lindgren]

--- Chris Newcombe <chris.newcombe@REDACTED> wrote:

> So to achieve more coverage of
> concurrency-interactions in the tests,
> I want to make a cheap, easy hack to the BEAM
> scheduler to make it
> less ploddingly deterministic on every test run.
> 
> One trivial way would be to use "erl -smp enable +S
> 2" (or more), to
> introduce more OS threads running Erlang processes. 
> But paradoxically
> that introduces some 'relatively uncontrolable'
> determinism (the OS
> scheduler), which could indeed find some
> concurrency-sensitive bugs,
> but might make them harder to reproduce (to verify
> fixes).
> 
> I'd prefer to introduce some more controlable
> determinism, e.g. by
> changing the size of the process quantum (the number
> of reductions it
> is allowed execute before it is pre-empted).
> Obviously we need to be careful to preserve
> fairness, avoid thrash etc.

Here are some other possibilities:

If future proofing is not an issue, and it doesn't
sound like it is, there is also the BIF
bump_reductions(N). You could, in principle, insert
conditional macroized calls to this to reschedule
earlier by draining more reductions. (Combined with
process_info to get the current number of reductions?)

Or you could record the trace of events with judicious
use of the trace BIFs and capture/process the faulty
ones. There is some scattered support for doing this
here and there in the OTP distribution, I believe.
That could be combined with your C code too,
presumably.

Another option might be to license QuickCheck :-)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com