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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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