Currently messages are stored in a simple list, which is appended to and popped from by the server in multiple threads. Although unlikely due to only one person adding and one person reading from the message list, all server actions are handled in independent threads and message ordering is critical to chat integrity. A race condition, which a queue would prevent, will prevent some possible cases where a message is read twice causing an error.
Queues not strictly necessary. Locking should be used when editing global dictionary items.
Overview of planned server data:
available_counselors (list[pubkey]) - lock during insert and delete
waiting_guests (queue[pubkey]) - no locks, counselors pop on match, guests add themselves to queue
active_chats (dict[pubkey->queue[message]]) - lock on chat start and end, message queues can be retreived, pushed to, and popped lock free
clients hold pubkeys for self (identity key, ephemeral chat) and the pubkey for their chat partner (ephemeral). chat POST requests use chat partner pubkey to add to their queue, chat GET requests use self pubkey to pull new messages from queue.
Currently messages are stored in a simple list, which is appended to and popped from by the server in multiple threads. Although unlikely due to only one person adding and one person reading from the message list, all server actions are handled in independent threads and message ordering is critical to chat integrity. A race condition, which a queue would prevent, will prevent some possible cases where a message is read twice causing an error.