memo = wire.memo()
memo = wire.memo( { fifo=handle , data={} , on_result=callback } )

Create a memo and return it, if you pass in a new table then that is the table we will modify and return.

So you can either get a fresh memo and then fill it or pass in a new table with values already set and have that tables meta adjusted to make it a memo.

memo.fifo must be provided as it is the destination. May be a fifo/thread (table) or a handle (number).

memo.data is the data to send and must be a table.

memo.result must be nil and will be set to the result when we receive it.

memo.sender can be provided or it will be set to our handle ( which is wire.thread.us.handle ) It must be a handle and it is where replies are sent.

memo.id can be provided or it will be generated. When receiving a memo, we must use the sent id or will not be able to reply. This will be handled by fifo.pull so best to consider it an internal value and not mess with it.

The memo will also be placed in wire.memos for later processing by wire, it will remain there until wire.update deals with result/fail callbacks and removes it. You may keep your own memo reference or rely on the callbacks to remind you. If you create a memo that does not get sent and replied to then you will have to remove it manually.

memo.state will be set to "setup"

if memo.on_result is provided then it will be called during wire.update after we get a reply. Note that a result may be a fail if result.fail is set. on_result will be called like so:

memo.on_result(memo)

With or without a callback, the memos that had results will then be removed by wire.update as there is nothing else for wire to do.

FYI HAX TBH : memo.id is set to a light userdata of the memo tables pointer, this should be unique across multiple lua states and threads in the same process, for as long as the table stays on the stack. A future lua garbage collection system could break this by moving tables around in system memory but I believe this is currently "safe" as of 2026 in currently available versions of lua/luajit and if that changes I will fix it. There exists some reqritw of lua from c to java etc, these probably work but you might want to double check.

memo:remove()

Remove a memo from wire.memos.

memo.state will be changed to "removed" and it can no longer be found in wire.memos

This means it is no longer a live memo as far as wire is concerned.

You may of course keep this memo around if you need it.

result = memo:resolve()
result = wire.memo(...):resolve()

If memo.state is "setup" then we memo:send() the memo. "setup" is the state a newly created memo will be in.

Wait for a result on our thread fifo ( wire.threads.us ) before returning.

Other memos may have been pulled and ignored for now. These memos can be found later in wire.memos

result is returned and can also be found in memo.result this should always be a table containing the result of the memo provided by the thread.

If a result was returned with result.fail set then the thread replied with a hard fail. A hard fail means the thread could not deal with your memo, so lua code broke, memo was invalid etc. This is a hard fail and will raise an error rather than return a result.

If the thread does not reply (probably a broken or missing task) then this will lock waiting on a result.

If the currently running thread is asked to halt then this will raise an error rather than return.

Note that this function ignores callbacks which are only called during wire.result

memo:reply()

Reply to a memo, this uses the senders handle as a fifo without it needing to be wrapped in a full fifo/thread.

memo.state will be changed to "reply"

memo:status(state)

Change status of memo, moving it between wire.memos[ memo.state ] caches.

This is a local function for local people. It should not be used by you.