You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using libcontainer as a library requires some care, as shown in #3011 and #2425.
This is mainly related to the safety of executing code after cloning the process.
In general, the more complex the process using libcontainer is, the more likely it is to hit unexpected or undefined behaviours.
This is particularly true for projects writing container shims based on libcontainer, where the shim is a long running process, either using threads, or an async runtime, or both.
Solution
As I mentioned in #3011, in runwasi we are planning to address this using a zygote process.
This is a process that's cloned very early in the main process lifetime, while it's still safe to do so.
This zygote process uses very basic IPC to receive commands and create new containers using libcontainer.
The zygote process is kept very simple to guarantee that when libcontainer does a clone, it's is done safely.
Proposal
I've created a zygote library to do this: https://crates.io/crates/zygote
But I think that zygote would benefit from being part of libcontainer.
I also believe that many use cases for libcontainer would benefit from a functionality like the one provided by zygote.
I would like to donate zygote to youki, potentially as part of libcontainer and with a better name.
I would like to hear your opinions.
The text was updated successfully, but these errors were encountered:
Thanks! I think this will be a kind of refactoring of libcontainer, but is my perception correct?
In other words, is it a proposal to use this library to create intermediate processes and init processes?
Context
Using
libcontainer
as a library requires some care, as shown in #3011 and #2425.This is mainly related to the safety of executing code after cloning the process.
In general, the more complex the process using
libcontainer
is, the more likely it is to hit unexpected or undefined behaviours.This is particularly true for projects writing container shims based on
libcontainer
, where the shim is a long running process, either using threads, or an async runtime, or both.Solution
As I mentioned in #3011, in
runwasi
we are planning to address this using a zygote process.This is a process that's cloned very early in the main process lifetime, while it's still safe to do so.
This zygote process uses very basic IPC to receive commands and create new containers using
libcontainer
.The zygote process is kept very simple to guarantee that when
libcontainer
does a clone, it's is done safely.Proposal
I've created a
zygote
library to do this: https://crates.io/crates/zygoteBut I think that
zygote
would benefit from being part oflibcontainer
.I also believe that many use cases for
libcontainer
would benefit from a functionality like the one provided byzygote
.I would like to donate
zygote
toyouki
, potentially as part oflibcontainer
and with a better name.I would like to hear your opinions.
The text was updated successfully, but these errors were encountered: