IPC considerations.

My kernel currently has one message inbox for each process. I am thinking of letting each process have as many inboxes as it desires (possibly limited to 32). That way, a process can have one inbox for high priority messages received from eg. an interrupt handler and another inbox for application IPC.

I ran into these thoughts when writing the USART device driver. I want to have one process in charge for the communication. Sending a message to it transmits the message contents over the wire. However, the process in charge needs to be aware of if the serial port data register is empty. The interrupt handler could, when it has sent the last byte of a message, send a message to the process in charge of communication, to it's "device driver" inbox.

This should be analog to a solution where reading from an inbox can be done, specifying what message types are wanted. The benefit of this solution is that the kernel always returns the first message in the queue, increasing performance. The drawback is that the number of selectable message types (when receiving) will be limited.