mirror of
https://github.com/fluffos/fluffos
synced 2026-08-12 18:26:06 -04:00
b0f61c3313
resolve(), async_read(), async_write(), async_getdir() and async_db_exec() ran their callbacks with no user context, so this_player() returned 0 and input_to()/printf() were unusable there. Follow the call_out() precedent: capture command_giver (ref-held) when the request is registered and restore it around the callback, skipping destructed objects, gated on the same 'this_player in call_out' setting. The pending-request holders account for the new ref in the DEBUGMALLOC walkers. The new test registers callbacks from two different living objects and asserts each callback sees its own registrant, which fails without the per-request capture. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lv2Gw2AWqtyN3nNEgob1He
961 B
961 B
| title |
|---|
| async / async_write |
async_write
NAME
async_write() - appends a string to a file then executes a callback
SYNOPSIS
void async_write( string file, string str, int flag, function callback );
DESCRIPTION
Append the string 'str' into the file 'file'. If flag is 1, write_file
overwrites instead of appending.
Unlike write_file, which returns 0 for failure or 1 for success, this efun
will return -1 for failure and 0 for success to the callback.
The callback should follow this format:
function (int res) {
// -1 for failure
// 0 for success
}
NOTE
When the 'this_player in call_out' driver setting is enabled,
this_player() inside the callback is preserved from the time the
request was made, like call_out().
SEE ALSO
file_size(3), read_file(3), write_buffer(3), write_file(3), async_read(3),
valid_read(4), valid_write(4)