On Mon, 28 Nov 2016 21:45:16 -0800 (PST) Thaniyarasu Kannusamy <thaniyar...@gmail.com> wrote:
> we all knows that sharing "Linux Kernel" is possible in container > world. i also want to know further that, > is sharing "Go Runtime VM" is possible in anyway ? > so we can able to share a common "Go Runtime VM" for many go > application. if that is possible then we can able to run 'Go Runtime > VM' effectively in serverless architecture. > > i know that 'Go Runtime VM' must be start from a "func main()" You might be confusing things here. The first thing to note is that Go implementations I know of do not currently implement the so-called "free-standing" compilation mode which would produce executables not requiring a particular kernel to work. Instead, the Go runtime which gets linked statically or dynamically to all the executables produced by Go compilers make heavy use of the kernel of the underlying host OS. In particular, it assumes the kernel implements virtual memory, threads, file and socket I/O, timers and other stuff. That is, as per your definition, the "serverless" would not have excluded the kernel itself out of the picture. Now, if you're okay with still having the Linux kernel in the picture, all you need to have a Go program work on a bare kernel is to change the command line of your kernel to include the init=/path/to/your/go/program string. After booting, the kernel would run the indicated program as its "pid 0" process (which is usually something colloquially called an "init process"). This is really no magic: you will have the kernel and the single process running on it. This way, you can have a working solution consisting of pretty much two or three files: the kernel image, your executable and (possibly) an initramfs image with the early boot environment for your kernel. Pretty much "serverless", I'd say. But then you should consider what happens if your single process dies for some reason. Obviously, if such a setup is intended for sustained service, you'd need something to monitor your process and restart it. If that's handled outside your kernel+process combo (say, a container solution handles this somehow) that's okay; otherwise you'd still need to have some "not-so-serverless" solution to provide intelligent restarting of your application and maybe logging. Now let's move to "the containers". The only means running programs interact with the kernel is by using the so-called "system calls" (or "syscalls" for short). Leaving aside the question of how they are actually implemented, the crucial fact about them is that performing a syscall has noticeable runtime overhead. What this leads us to is that should you somehow "factored out" the Go runtime, you'd need to turn it into pretty much the same kind of "service" the kernel is to the processes: it'd need to implement something akin to syscalls, and these would have considerable call overhead -- simply due to the reason you'd need to protect that VM from the Go processes it powers. If you're okay with giving up protection (that is, it's okay for any Go process to crash the VM and bring down the other Go processes running on it), let's see what is left. Go runtime basically implements management of the goroutines -- their requirements for memory (stacks and heap) and I/O -- and provides a set of library functions. I fathom the overhead of the Go runtime scheduler in terms of CPU and memory is not that big so that if you would have just a single instance of it per N Go processes, it would make any noticeable difference. You have mentioned sandboxing implemented in node.js. That could possibly be done to our imaginary "Go runtime host process" as well but sandboxing is a very complex stuff, prone to bugs. Node appears to get that "for free" -- merely by virtue this stuff is implemented by the JS engine it piggybacks on (actually, that's the whole reason Node came to existence: someone got bored enough to notice that a typical browser's engine these days has support for both JS and networking at the same time). I'm not sure it's sensible to tread the same road: the OS does process separation just OK, and if you want, you have more powerful stuff to help it -- such as AppArmor/SELinux and seccomp. In-kernel support for containers (actually, it's all about resource "namespacing" and having separate limits for them) is essentially also about "sandboxing" -- just on another level. To round up, I think you got hooked onto some buzzwords a bit. The fact node.js does X does not mean X is good or at all needed. ;-) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
