[erlang-bugs] Dirty schedulers and '-smp disable'

[Knut Nesheim]

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 <vinoski@REDACTED> wrote:
>
>
> On Tue, Jun 30, 2015 at 10:39 AM, Knut Nesheim <knutin@REDACTED> 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