Receive is non-atomic w.r.t. signals

[NicolasT]

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 (or receive etc.) will receive a signal (asynchronous exception), and fail. No harm done.

However, if for some reason the receiveWithOptions call is within a catch, 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 the receive implementation into the handler, and the message we selected (and removed from the mailbox) before is lost: upon a subsequent receive (after recovery from the exception), it will never be returned.

[NicolasT]

Having #11 (CQueue work in STM) would likely help, since then we can in a single transaction, lookup some message, as well as wait for signals to be delivered. If a signal is delivered (and hence, due to an asynchronous exception, the call to receiveWithOptions and the transaction it runs being interrupted), the whole transaction is reverted and whatever message was chosen goes back in the queue, so to say.

Then, if the exception is caught, a new call to receive could still find the message, or (more likely), the process just terminates and the message isn't ever handled.

[NicolasT]

Actually, I'm not even sure there's a bug here. When one wants to receive a message "atomically", the receive itself should be under a mask, otherwise all bets are off.

Now, having CQueue being STM-based would "simplify" things, as in, an asynchronous exception being raised in "our" code won't result in a message being lost. However, once receive returns, before a next bind, the exception could come in and make things fail.

So, unless I'm mistaken, this is not a bug at all.