erlang icon indicating copy to clipboard operation
erlang copied to clipboard

Add some better error handling with named pid `receive()` and `receive_forever()`

Open mjsir911 opened this issue 3 months ago • 4 comments

This is all kind of assuming that there can only be one pid registered to a name, but I think that's correct?

doesn't add a named process receive_forever test but I can add that in as well pretty easily.

mjsir911 avatar Sep 23 '25 19:09 mjsir911

this currently doesn't handle the possibility of:

  1. main process is registered to a name
  2. main process gets sent some data
  3. the name gets re-registered to a different process
  4. the main process then tries receive()ing on the named subject, to get the data that's existed on the mailbox
  5. previous behavior: would succeed, and allow any number of receive()s on names that the process is not registered to. current behavior: fails because the process is not registered to the name, even if there is some data for it in the mailbox. maybe this warrants a receive_unchecked()?

mjsir911 avatar Sep 23 '25 21:09 mjsir911

Hello!

That's an interesting point about messages in the inbox from a previously registered name. I wonder what would be best to do about that.

lpil avatar Sep 25 '25 16:09 lpil

That's an interesting point about messages in the inbox from a previously registered name. I wonder what would be best to do about that.

maybe just verify that the subject is owned by the current process on subject creation, store it within the namedsubject & then assume it's receivable on?

could also just give out a warning? or something? if receive is run on a non-owned named subject

mjsir911 avatar Sep 25 '25 18:09 mjsir911

That would mean that only the subject owner could make the subject, which would defeat the purpose of names!

How about we document that a selector can be used if they want to avoid this check.

lpil avatar Sep 27 '25 16:09 lpil