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
920 B
920 B
| title |
|---|
| async / async_read |
async_read
NAME
async_read() - read a file into a string then executes a callback
SYNOPSIS
void async_read( string file, function callback );
DESCRIPTION
Read a line of text from a file into a string. Normally, read_file
takes a second and third arguments for start_line and number_of_lines to
read, but async_read will return the entire file to the callback.
The callback should follow this format:
function(mixed res) {
// -1 for file not read
// string file contents otherwise
}
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_buffer(3), read_file(3), write_file(3), async_write(3),
valid_read(4), valid_write(4)