This is a simplified message processing loop. I've added close signal processing to it, but the logic for doing so is very strange: after the close signal is sent, you still need to wait for the next message to be received before you can close it. I envision manually handling the close rx poll method first and then the message, but I don't know how to pin it. select! doesn't seem to fit this case (or maybe I didn't think of a way to use it).
If all msg_txs are dropped, or close_tx send a message, then exit; if a message is received, then process it; if close_tx is dropped, then panic. There should be no other cases.
You should wait for the close to finish before returning from main. See this page for an example of that.
Another thing to note is that your current code will not exit during a call to process. If waiting for process to return before exiting is what you want, then this is ok, but if it is not what you want, then you would need to change it.
It is a intended behavior to process all the requests that have been already received and then exit. But I don't understand what I have to do to "wait for the close to finish".
The None branch of matching msg_result should have a close() before break. I just forgot to add it.
Thanks for reminding. Given my previous experience with implementing a channel wrapper that can respond to messages (i.e. requests), I think it would be possible to pass another oneshot channel in the oneshot channel used to pass the close signal, and "respond" to the main thread after the close is complete.