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