Skip to content
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

question about DIST: SPAWN_REQUEST-SPAWN_REPLY. Always returns PID in the reply. #8603

Closed
halturin opened this issue Jun 21, 2024 · 4 comments
Labels
not a bug Issue is determined as not a bug by OTP team:VM Assigned to OTP team VM

Comments

@halturin
Copy link
Contributor

halturin commented Jun 21, 2024

I'm playing with the "spawn request" feature (introduced in OTP 23) and didn't get the behavior.

On any SPAWN_REQUEST I receive SPAWN_REPLY with a pid. Even if I use random names for the "module" and/or "function" it returns a pid. I was expected to see an error on the failure of spawning. How can I ensure that the PID I'm receiving is a PID of the real process? not the fake one.

There are no details about that in the docs.

@halturin halturin added the bug Issue is reported as a bug label Jun 21, 2024
@IngelaAndin IngelaAndin added the team:VM Assigned to OTP team VM label Jun 22, 2024
@garazdawi
Copy link
Contributor

Why do you need to know that? The only way to know that the process successfully started is by it sending a message back to you or if you monitor/link to it.

@halturin
Copy link
Contributor Author

halturin commented Jun 24, 2024

I'm the author of Ergo Framework https://github.com/ergo-services/ergo. It implements Erlang network stack in golang https://github.com/ergo-services/proto (this implementation for the coming release of Ergo Framework 3.0).

@jhogberg
Copy link
Contributor

jhogberg commented Jun 24, 2024

Thanks for your report! This is the intended behavior. The process won't crash until it tries to run the bogus MFA that you have specified, which it cannot do until it has been successfully spawned. In interactive mode it will also attempt to load the module in question, which may or may not succeed, and we cannot hold off on SPAWN_REPLY for that.

As @garazdawi mentioned, if you want to know how things went after the process was spawned, either have it send a message or monitor/link it.

@jhogberg jhogberg added not a bug Issue is determined as not a bug by OTP and removed bug Issue is reported as a bug labels Jun 24, 2024
@halturin
Copy link
Contributor Author

Thanks for the clarification

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not a bug Issue is determined as not a bug by OTP team:VM Assigned to OTP team VM
Projects
None yet
Development

No branches or pull requests

4 participants