Re: Dirty schedulers and '-smp disable'
Knut Nesheim <[email protected]> Wed, 1 Jul 2015 10:25:35 +0200
| Newsgroups | gmane.comp.lang.erlang.bugs |
|---|---|
| Message-ID | <CACSRAtXw33oELwFR4O4Ppycr3mgozTQOUwAR7Pjmm9JqUK+-Rw@mail.gmail.com> |
Yes, your answer makes sense. Just to clarify, the VM has been built with smp support, but when it boots up on a single-core machine it doesn't enable smp because it only detects one logical processor. I was able to reproduce the "dirty nif stuck" problem with "erl -smp disable". Knut On Tue, Jun 30, 2015 at 5:06 PM, Steve Vinoski <[email protected]> wrote: > > > On Tue, Jun 30, 2015 at 10:39 AM, Knut Nesheim <[email protected]> wrote: >> >> Dear list, >> >> I ran into unexpected behaviour in the following situation: >> >> * OTP 18.0, compiled from the git tag with dirty schedulers enabled >> * NIF with the ERL_NIF_DIRTY_JOB_CPU_BOUND flag >> * Small machine with only one core (AWS t1.micro) >> * The first log line from startup with no explicit flags looks like >> this: Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> When I call the NIF, the calling process hangs forever. When I call it >> from the shell, I'm unable to interrupt the process (C-g, i 1 does >> nothing useful). >> >> If I explicitly use '-smp enable' as arguments to erl, the NIF runs >> fine. In that case the first log line looks like this: Erlang/OTP 18 >> [erts-7.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:10] >> [hipe] [kernel-poll:false] >> >> This behaviour got me a bit confused, as there is no indication what >> is happening except "something somewhere got stuck". It's not a common >> case for me, as most machines have multiple cores except tiny cloud >> instances or virtual machines. > > > The short answer is that currently, dirty schedulers always require SMP. > > The longer answer is that configure should raise an error if this > configuration is attempted. I can't recall for sure but I think it behaved > like this at one point, but a lot changed for Erlang 18 and so perhaps this > config check got lost along the way. > > --steve _______________________________________________ erlang-bugs mailing list [email protected] http://erlang.org/mailman/listinfo/erlang-bugs