#4327 and some discussions we had in the last few days showed, that we really are in the need of some alternative (or completely overhauled) IPC, that does not rely on threads and maybe has some kind of prioritization, too. This issue is here to discuss the general specification of such architecture (because doing so proofed to be a success in with GNRC ;-)):

I was thinking about something in the line of a centralized, thread-safe, priority queue for messages

• Data type: message queue… let's call it message box (mbox_t) to not confuse it with the threaded message queues.
• Operations:
  • int mbox_put(mbox_t *mbox, msg_t *msg, int prio) (equivalent to msg_send())
  • int mbox_try_put(mbox_t *mbox, msg_t *msg, int prio) (equivalent to msg_try_send())
  • int mbox_get(mbox_t *mbox, msg_t *msg) (equivalent to msg_receive())
  • int mbox_try_get(mbox_t *mbox, msg_t *msg) (equivalent to msg_try_receive())
• optional operations (e. g. through a submodule)
  • int mbox_put_timed(mbox_t *mbox, msg_t *msg, int prio, xtimer_t *timer, uint32_t offset) (equivalent to xtimer_set_msg())
  • int mbox_put_timed64(mbox_t *mbox, msg_t *msg, int prio, xtimer_t *timer, uint54_t offset) (equivalent to xtimer_set_msg64())
  • int mbox_get_timeout(mbox_t *mbox, msg_t *msg, uint32_t timeout) (equivalent to xtimer_msg_receive_timeout())
  • int mbox_get_timeout(mbox_t *mbox, msg_t *msg, uint64_t timeout) (equivalent to xtimer_msg_receive_timeout64())

I'm not sure if equivalents for msg_send_receive() and msg_reply() are necessary (probably not), but they can be added as wrappers for mbox_put() and mbox_get() respectively, I guess.