[erlang-questions] enif_send backpressure

[Felix Gallo]

If your NIF is running in a process managed by the scheduler, then as long
as it uses enif_consume_timeslice appropriately, then if it sends a message
to a loaded queue, it will get penalized by a large number of reductions,
get deprioritized, yield, and be dropped to the bottom of the run queue,
unless I'm misunderstanding.  If one of the other tens of thousands of
squirrels are runnable with a higher priority, they will take over the run
slot.

That way you wouldn't have to reach into the internals of another process
to make your own determination, which seems like it'd be a better idea.
But again, perhaps I'm confused.

F.

On Thu, May 25, 2017 at 12:11 PM, Roger Lipscombe <roger@REDACTED>
wrote:

> On 25 May 2017 at 18:07, Felix Gallo <felixgallo@REDACTED> wrote:
>
>> Rather than dive into the details of another process, wouldn't it be more
>> erlang to use enif_consume_timeslice (http://erlang.org/doc/man/erl
>> _nif.html#enif_consume_timeslice) and/or dirty nifs and just let the
>> scheduler do its thing?
>>
>
> This stuff's running on a background thread. Specifically, it's running a
> Squirrel VM (squirrel-lang.org) on a background thread. Some of the calls
> in the squirrel code result in enif_send to the accompanying (1:1) Erlang
> process. I'd like the squirrel to (briefly) pause[1] if the Erlang process
> has too many messages in its queue.
>
> [1] not actually pause; we're running 10s of thousands of these on a pool
> of background threads, we want the one that's calling enif_send too
> frequently to yield, *exactly* the same as an Erlang process would do.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170525/11275608/attachment.htm>