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

[Kenji Rikitake]

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