Replies: 2 comments 15 replies
-
This will need modifying LightProcess, but it would be much better to natively expose an Awaitable; we generally consider wrapping callbacks to awaitables promise-style to be an antipattern, and it's intentionally awkward to do. |
Beta Was this translation helpful? Give feedback.
-
Shall we expose some functions of newtype LightProcess = mixed;
// General LightProcess functions
<<__Native>>
function select_read_async(LightProcess $proc): Awaitable<void>;
<<__Native>>
function release_light_process(LightProcess $proc): void;
<<__Native>>
function acquire_light_process(): LightProcess;
// waitpid functions
newtype stat_loc = int;
<<__Native>>
function write_waitpid(LightProcess $proc, pid_t $pid, int $options = 0): void;
<<__Native>>
function read_waitpid_result(LightProcess $proc): stat_loc; The current implementation of async function waitpid_async(pid_t $pid, int $options = 0): stat_loc {
$proc = acquire_light_process();
try {
write_waitpid($proc, $pid, $options);
await select_read_async($proc);
return read_waitpid_result($proc);
} finally {
release_light_process($proc);
}
} |
Beta Was this translation helpful? Give feedback.
-
Hi all, I am working on a new HSL API for creating subprocesses. One of the goals is to make the new API completely asynchronous. Unfortunately, currently we don't have a good mechanism to wait for the exit code of a subprocess asynchronously.
I think we could expose a Hack function calling
LightProcess::SetLostChildHandler
to solve the problem if LightProcess is enabled, and provide a fallback implementation to wait for the exit code synchronously when LightProcess is not enabled.The proposed native function would like this:
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions