-
Notifications
You must be signed in to change notification settings - Fork 2
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
Receive is non-atomic w.r.t. signals #29
Comments
Having #11 ( Then, if the exception is caught, a new call to |
Actually, I'm not even sure there's a bug here. When one wants to receive a message "atomically", the Now, having So, unless I'm mistaken, this is not a bug at all. |
I'm not entirely sure this is a bug, but leaving it here for future consideration.
In
receiveWithOptions
, we check for pending signals after finding a message in the mailbox, and removing it from the mailbox. When there are pending signals, these are delivered, and then the message is yielded (cfr. #25).In general, this is fine: a caller of
receiveWithOptions
(orreceive
etc.) will receive a signal (asynchronous exception), and fail. No harm done.However, if for some reason the
receiveWithOptions
call is within acatch
, and the process recovers from whichever signal/exception is sent to it (which is tricky to get right in the first place), we kind of jump from thereceive
implementation into the handler, and the message we selected (and removed from the mailbox) before is lost: upon a subsequentreceive
(after recovery from the exception), it will never be returned.The text was updated successfully, but these errors were encountered: