[erlang-questions] enif_send backpressure

[Roger Lipscombe]

My call to enif_send is from a non-Erlang background thread. Thread yield
and sender punish don't *mean* anything. I'll be implementing the
sender-punish / thread-yield in the squirrel bindings. So *I* need to know
whether to do that or not -- hence returning the queue length of the
recipient.

On 25 May 2017 at 21:41, Daniel Goertzen <daniel.goertzen@REDACTED> wrote:

> Could the existing implementation of enif_send() do a thread yield when
> sending to a congested process?
>
> The first env param will tell you if this is a created thread or process
> thread, so either a thread yield or sender punish could be performed.
>
>
> On Thu, May 25, 2017 at 7:44 AM Roger Lipscombe <roger@REDACTED>
> wrote:
>
>> On 25 May 2017 at 13:20, Roger Lipscombe <roger@REDACTED> wrote:
>>
>>> It's my understanding that if a normal Erlang process does Pid ! Msg,
>>> and Pid has a particularly full message queue, then the sending process is
>>> penalised (gives up the remainder of its timeslice, e.g.).
>>>
>>
>> I found the relevant code. Search for erts_use_sender_punish in the OTP
>> source.
>>
>> Is there any way to implement something similar for enif_send from a NIF?
>>>
>>
>> Note that enif_send calls erts_queue_message, which *does* return the
>> recipient's queue length (afaict). It's just that enif_send discards the
>> result. Would a PR which implemented (e.g.) enif_send_return_len -- naming
>> is hard, suggestions appreciated -- be considered for OTP 20.x?
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170526/6851806c/attachment.htm>