[erlang-questions] High Priority processes not handling system tasks

[Rickard Green]

I don't know why this mail only ended up in the archive, but not in my
mailbox...

> G’Day,
> Below is a chunk of code that does not look bad at a first
> glance, but…
>
> start() ->
>     Pid = spawn(?MODULE, high, []),
>    io:format("Starting... "),
>    erlang:check_process_code(Pid, rec),
>     io:format("collected~n").
>
> high() ->
>     erlang:process_flag(priority, high),
>     endless(10).
>
> endless(X) ->
>     endless(X+1).
>
>
> start() never returns, because check_process_code schedules a normal
priority
> system task against high priority process. It seems to be logical, but
leads to
> some really weird effects. For example, code:soft_purge() hangs (in
> erts_code_purger, cpc_receive), thus whole code_server gen_server hangs,
> and this paralyses almost everything (a separate issue - cpc_receive has
no
> receive timeout at all, possibly stalling whole VM).
>
> Is it designed behaviour? I have quite a straightforward solution (patch
for
> erl_process.c), but I might now understand consequences.
>
> Applies to R19+ (with 'new purge strategy' enabled). Older releases (eg.
R16B)
> are not affected.
>
>
> Regards,
>
>  Maxim Fedorov

Yes this is how the process priority scheme was intentionally designed (for
better or for worse). 'high' and 'max' process priority work are alway
selected before lower process priority work.

Changing the behaviour of system tasks so that lower priority tasks are
interleaved with 'high' and/or 'max' priority work essentially introduce
intentional priority inversion.

Utilization of 'high' and 'max' priority has to be done with outmost care.
Using high or max priorities on processes that hogs the cpu very likely
will get you into trouble. The documentation of process_flag(priority, _)
is also quite clear on this.

This question comes up every now and then. In the past we have always
rejected proposals for priory tweeks like this. I'm not claiming this
priority scheme is the ultimate scheme, but this is what we have and I
think we should stick with it as it is or redesign it from scratch.

Regards,
Rickard
-- 

Rickard Green, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180526/4540d370/attachment.htm>