[erlang-questions] How long a NIF can block the Erlang BEAM?

[Paul Davis]

On Tue, Nov 23, 2010 at 6:00 AM, Kenji Rikitake <kenji.rikitake@REDACTED> wrote:
> Thanks Alceste and Mattias.
>
> I was thinking about using SFMT instead of the random module, and was
> worrying about the scheduling disruption issue.  Functions in the random
> module is found at many places among the Erlang/OTP libraries, so I
> thought I had to be conservative.
>
> The enif_thread_create() and enif_send() pair Alceste wrote looks very
> interesting, though I also guess it's a bit too complicated for a random
> number generator.
>
> Regards,
> Kenji Rikitake
>
> In the message <20101123103040.GA3635@REDACTED>
> dated Tue, Nov 23, 2010 at 11:30:16AM +0100,
> Matthias Lang <matthias@REDACTED> writes:
>> Kenji> >I wonder how long a NIF can block the Erlang BEAM.  To put it another
>> Kenji> >way, I want to know the maximum time allowed a NIF can run in the
>> Kenji> >BEAM.
>> Kenji> >One millisecond? Or 100 microseconds? Or even shorter?
>>
>> Alceste> AFAIK, there are no hard limits: a NIF could block its Erlang
>> Alceste> VM thread as long as needed --- but long-running NIFs will
>> Alceste> disrupt the scheduling of other Erlang processes, and reduce
>> Alceste> the responsiveness of unrelated applications running in the
>> Alceste> same VM.
>>
>> Exactly. The limit is whatever the tolerable latency in your
>> application is. If it's fine for your application to freeze for 500ms,
>> then a NIF which takes 500ms to run is ok.
>>
>> The rest of Erlang is made so that an application can react to things
>> within a few milliseconds, so 100 microseconds is unlikely to give
>> anyone a nasty surprise. 100 milliseconds will.
>>
>> Matt
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>

Quite randomly I just implemented this yesterday. I haven't tested
this code other than to check that send_to_self works in the Erlang
shell and it survives an init:restart/0 which can wreak havoc with
thread maintenance.

https://github.com/davisp/nif-examples/blob/master/termsend_threaded/c_src/termsend_threaded.c

Its pretty much just what's being discussed. A thread is spawned in
the load function and waits for requests from Erlang for a random
number.

HTH,
Paul Davis