3 ms·
Note my nomenclature here is parent (doesn't block), worker (calls vfork), and child (calls execve). If you used vfork then the worker doesn't unblock until ex
by fc417fc802 2y ago
Note my nomenclature here is parent (doesn't block), worker (calls vfork), and child (calls execve).
If you used vfork then the worker doesn't unblock until execve has executed successfully (AFAIU). In that case if the exec succeeded then nothing will have been written whereas if it failed then the child will have written out the error code to the worker's stack before calling _exit.
The worker can then use an atomic write to communicate the ultimate result back to the parent in an asynchronous manner.
- cryptonector 2y agoAh, yes, that's true. I'm so used to using pipes like this that I forgot. You're quite right. Though I'd still use something like a pipe rather than a condition variable, say, because on Unix and Linux systems you can't have an event loop handle events on file descriptors _and_ condition variables.
- cryptonector 2y agoAnd those are my favorite signalling mechanisms: async I/O and condition variables.
- fc417fc802 2y agoI thought the optimization goal was latency on the parent thread so I had in mind a bare atomic_store_explicit with memory_order_relaxed. However you wouldn't care about latency in the first place if you weren't scaling this up and obviously scaling up requires additional infrastructure that I'm ignoring here. That said the linked article is using spawn_blocking from tokio meaning you can just call vfork directly and return the result. No need to roll your own in this case. > you can't have an event loop handle events on file descriptors _and_ condition variables Since events crossing the kernel boundary aren't fast to begin with I prefer to use a secondary event loop for the sluggish stuff and feed the output to the lower latency one.