Re: Dirty schedulers and '-smp disable'

That's fair. Although I don't care that they don't work on non-SMP
VMs. It was just that they failed in a non-obvious manner. For
instance, an error when loading a NIF that specifies a dirty scheduler
in an ErlNifFunc or when passing a dirty scheduler flag to
enif_schedule_nif would've probably been enough to point out the
issue.

On Wed, Dec 2, 2015 at 8:53 AM, Steve Vinoski <[email protected]> wrote:
>
>
> On Tue, Dec 1, 2015 at 9:04 PM, Paul Davis <[email protected]>
> wrote:
>>
>> I just butted up against this as well. Testing some code on a single
>> core virtual box vm and wasn't used to smp being disabled by default.
>> I've reproduced the behavior exactly as Knut described.
>>
>> One thing further that was also icky is that the ErlNifSysInfo struct
>> has the dirty_scheduler_support flag set to 1 even when dirty
>> schedulers don't work (due to smp being disabled on single core VMs).
>> Thus, if you want to be super duper certain you have to check that
>> smp_support is enabled as well. While not a terrible inconvenience
>> once you know about it, I definitely managed to spend two hours
>> figuring it out.
>
>
> That too seems like a bug, for now anyway.
>
> Only the OTP team can authoritatively state the plans for dirty schedulers,
> but I'm still involved in working on them and my understanding is there's a
> push to get them out of experimental status and into regular feature status
> for Erlang 19. Part of that push includes an effort to make them work even
> if SMP is disabled.
>
> --steve
>
>
>>
>>
>>
>> On Wed, Jul 1, 2015 at 4:25 AM, Knut Nesheim <[email protected]> wrote:
>> > 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
>
>
_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs