-
Notifications
You must be signed in to change notification settings - Fork 3k
[erts] Expose parent process via process_info(_, parent) #5768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[erts] Expose parent process via process_info(_, parent) #5768
Conversation
CT Test Results 3 files 125 suites 36m 40s ⏱️ For more details on these failures, see this check. Results for commit df95635. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
e1c1496
to
3775bb3
Compare
@max-au However, this "orphaned" process creation is used as part of RFC: Erlang Dist Filtering for the Erlang processes spawned to accept or reject the incoming dist command. There may be a different way to accomplish this, though, but I thought it worth mentioning that |
1d5e097
to
aa3e157
Compare
Fixed a bunch of typos and updated documentation. I see two ways to solve a problem with
|
@max-au sorry for later answer. It has been really busy lately... Regarding
I don't see any major issues with |
@max-au If a remote parent is not set, it seems best to have the parent in that case be |
Yes, I agree |
aa3e157
to
f2560cf
Compare
Parent process information is available in the VM process structure, but is not exposed via process_info. Sometimes it is very convenient to know who spawned processes that are not supporting any OTP behaviours (where this information is stored in a process dictionary). Parent process is returned only for locally started processes. Remotely started process, or 'init' process that has no parent, return 'undefined'.
I updated this PR:
I explained my thought process for |
f2560cf
to
d0e45b4
Compare
Yes, I think I've pushed a commit which adds support for remote parents. We are really soon about to release 25-rc2. This wont make it into rc2, but I'll put this into testing as soon as rc2 is out. |
a6d3d61
to
df95635
Compare
Thanks! |
I happened to have this PR in works as well. It introduces Every N seconds we iterate over processes to find the queue fill/drain rate. This way we find processes that are building up queues over time. It can also be implemented as part of |
I guess you by "total queue size" mean the value in It is okay to base such functionality on this value as long as it does not claim it is measuring the message queue length. Calling it signal queue length is okay, though.
What do you mean would be more expensive for all users? Repeated
I don't see it as acceptable that users not interested in this should pay an, other than negligible, performance/memory loss for this. If extra complexity is needed in order to achieve this, I see that as unavoidable. Using PSD for holding data related to this type of monitoring would also not be as costly memory wise if only enabling this on a subset of processes. |
Exactly what type of system monitor limit one would want I think it is good to discuss at Erlang forums. My guess is that a system monitor limit on signal queue length would be appreciated by many and would also not require any extra process specific memory usage. This is probably something that should be added regardless of whether more even "fancier" system monitor limits are added or not. |
@max-au I spoke without thinking... This is not signal queue length either, so one cannot document it as such. It actually is not possible to give a good description of what it represents except under certain very specific conditions. Its value is somewhere between message queue length and some definition of signal queue length. So by using it one will get some sloppy value of something that is a message-signal queueish lenghtish yuck... :-( At the moment I'm too tired to think of alternatives, but I'll try to figure something out later... |
I am thinking of it as a "total amount of messages" sent to the process (both in the queue and in flight). The caveat I see is that signals are also counted towards sig_qs.len and it would be expensive to keep track of non-message signal count (and in fact NM-signals are also affecting process performance/reductions). |
I understand it that both signals and messages must be handled by the process so in practice they all add to the backlog of things the process has to handle. And it is processes beginning to get a too big backlog we want to catch with the system_monitor. |
@max-au wrote:
It is only message signals included in When having a look at the code I also realized that in the case you got a process info request signal in the queue, updates of That is, it is more or less impossible to describe what the @KennethL wrote:
Yes such a system monitor limit is preferably based on some definition of signal queue length. A gen server call implies 3 signals ( |
If using If the system detects an amount of incoming messages higher then |
@rickard-green I wonder how long it might take for Implementation that does not take |
It can take a very long time and it can contain a huge amount of signals. There is no hard upper limit.
I don't see it as viable to take
No it can not be described as message queue length. Not even before receive markers. It is a mixture of message queue length and the amount of some messages in transit, but with hickups which can give you values less than message queue length. If one were to use it, one needs to document it as something extremely fuzzy like in my comment above. Otherwise, someone will want a bug fix on it some day. |
Parent process information is available in the VM process structure,
but is not exposed via process_info. Sometimes it is very convenient
to know who spawned processes that are not supporting any OTP
behaviours (where this information is stored in a process dictionary).
In addition to counting reductions, it may also be important to keep
track of total number sent to a process. This allows various monitoring
scenarios. For example, when message_queue_len is draining slowly, is
it because it the process being slow, or is it because it gets more
messages enqueued. Having both message_queue_len and messages_enqueued
provides a way to calculate queue fill rate (or drain rate) over time.