For example, there’re lots of program that uses subprocess in python or exec.cmd in golang. Those programs have to be ported to rewrite with the api bindings.
On Tue, Nov 26, 2019 at 9:06 AM Nadav Har'El <[email protected]> wrote: > > On Tue, Nov 26, 2019 at 12:44 AM Waldek Kozaczuk <[email protected]> > wrote: > >> Sometimes it might be more useful to think of unikernels as highly >> isolated processes instead of microVMs with a specialised guest OS. See >> Nabla processes - >> https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf. >> >> So given that I wonder if it would make sense/be feasible/applicable to >> implement limited fork/execve in OSv. It could work like this: >> >> 1. fork() starts new thread T2 - acts as "stub/proxy" to a new remote >> microVM that would be lazily started when execve() is actually called >> >> >> 1. tid of the new thread T2 would be returned to the caller in the >> thread T1; it would act as PID of the new process >> 2. New thread T2 would start with same code as calling thread T1 but >> somehow (???) get 0 as the return value and continue from there (just like >> on normal Posix OS) >> 3. T2 typically would call execve() right away >> 4. >> - execve() would somehow communicate with host (how?) to start new >> child VM with passed in command line, argv >> - execve() would never return and instead wait unit the child VM >> terminates >> - T2 would also somehow listen for some other calls like kill() >> and pass it to the host that would shutdown child VM >> >> Something like this is doable (and I vaguely remember someone from the > Mikelangelo project once thought about doing this), but I wonder which kind > of applications this would be useful for. I would start with finding such > an application before spending too much effort on this. > > >> There is obviously a plethora of various IPC mechanisms to communicate >> between processes (shared filesystem, shared memory, named semaphores, >> named semaphores, etc) so how much OSv would need to implement them to make >> such fork/execve useful, I do not know. I am also not sure if that would be >> applicable in any real-world scenarios. Maybe master-worker types of >> workloads (kind of what nginx model is).' >> >> Do not be too harsh if you think this is really stupid idea ;-) >> >> Waldek >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OSv Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/8f1e8b08-1028-4075-8298-fe72823da3cf%40googlegroups.com >> <https://groups.google.com/d/msgid/osv-dev/8f1e8b08-1028-4075-8298-fe72823da3cf%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BZxLquMMNPuvm7Miuv%2BYkA8h4q0G9C3eorr3vB%3Du4dg%40mail.gmail.com > <https://groups.google.com/d/msgid/osv-dev/CANEVyjv%2BZxLquMMNPuvm7Miuv%2BYkA8h4q0G9C3eorr3vB%3Du4dg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CA%2B3q14yTEZ9hoHvMsfP-k-mBPpZfDxTUf8sqDNwQ0SN-Yw5y8A%40mail.gmail.com.
