<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 10:39 AM, Knut Nesheim <span dir="ltr"><<a href="mailto:knutin@gmail.com" target="_blank">knutin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear list,<br>
<br>
I ran into unexpected behaviour in the following situation:<br>
<br>
 * OTP 18.0, compiled from the git tag with dirty schedulers enabled<br>
 * NIF with the ERL_NIF_DIRTY_JOB_CPU_BOUND flag<br>
 * Small machine with only one core (AWS t1.micro)<br>
 * The first log line from startup with no explicit flags looks like<br>
this: Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10]<br>
[hipe] [kernel-poll:false]<br>
<br>
When I call the NIF, the calling process hangs forever. When I call it<br>
from the shell, I'm unable to interrupt the process (C-g, i 1 does<br>
nothing useful).<br>
<br>
If I explicitly use '-smp enable' as arguments to erl, the NIF runs<br>
fine. In that case the first log line looks like this: Erlang/OTP 18<br>
[erts-7.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:10]<br>
[hipe] [kernel-poll:false]<br>
<br>
This behaviour got me a bit confused, as there is no indication what<br>
is happening except "something somewhere got stuck". It's not a common<br>
case for me, as most machines have multiple cores except tiny cloud<br>
instances or virtual machines.<br></blockquote><div><br></div><div>The short answer is that currently, dirty schedulers always require SMP.</div><div><br></div><div>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.</div><div><br></div><div>--steve</div></div></div></div>