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
2. 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
3. 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)
4. T2 typically would call execve() right away
5.
- 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
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.
