> It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever
Do you know much memory is used for a thread? Or for a process? The answer for either is not zero. In fact it is possible (but not used) for the same Dalvik process to host multiple apps.
> It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
Not even close. With swapping the kernel has to operate in units of 4kb pages. Dalvik can use a compacting garbage collector to reduce memory consumption. Signals are trivial. They are a single number, and not come even remotely close to interprocess resources. Think something closer to dbus, plus a bunch of code built on top of it.
> don't care about something "analogous" to libc, just give me libc and you don't have to do any work
Android already includes that (bionic). You can compile elf binaries that work just fine. Heck you'll even find 'ls' etc on the system done that way. But your binary won't be able to examine the clipboard.
Note the posting was about writing Android applications in Go, not about trivial binaries. Applications means all the crud you are dismissing.
> Are you assuming the necessity of a one to one mapping between Java API functions and C API functions?
Nope. But those functions only have a Dalvik hosted Java centric implementation. If you want to work with them then they all have to be reimplemented in a compatible manner, or you need to call from the native code back into Dalvik using JNI. Either way is a lot of work.
Your example of porting a Linux daemon to a service won't work as is. Being a service means the system has expectations of you - how you are started, how data is provided and returned and how it is stopped. (There is also other stuff such as permissions and process hosting.) The canonical way of doing this is to write the service front end in Java, and then use JNI to load native code you need. But it does mean your native code needs to play well with others in the same process - something that isn't Go's sweet spot.
In your scenario there are several SSH servers available. Most are delivered as a single "app", but behind the scenes consist of an sshd binary, plus Java authored code to provide a UI (start/stop/status/configuration) and manage lifecycle.
The desire from most folk is for Go authored apps to be first class citizens, and not require using any other language. That is what is a lot of duplicate work.
Do you know much memory is used for a thread? Or for a process? The answer for either is not zero. In fact it is possible (but not used) for the same Dalvik process to host multiple apps.
> It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
Not even close. With swapping the kernel has to operate in units of 4kb pages. Dalvik can use a compacting garbage collector to reduce memory consumption. Signals are trivial. They are a single number, and not come even remotely close to interprocess resources. Think something closer to dbus, plus a bunch of code built on top of it.
> don't care about something "analogous" to libc, just give me libc and you don't have to do any work
Android already includes that (bionic). You can compile elf binaries that work just fine. Heck you'll even find 'ls' etc on the system done that way. But your binary won't be able to examine the clipboard.
Note the posting was about writing Android applications in Go, not about trivial binaries. Applications means all the crud you are dismissing.
> Are you assuming the necessity of a one to one mapping between Java API functions and C API functions?
Nope. But those functions only have a Dalvik hosted Java centric implementation. If you want to work with them then they all have to be reimplemented in a compatible manner, or you need to call from the native code back into Dalvik using JNI. Either way is a lot of work.
Your example of porting a Linux daemon to a service won't work as is. Being a service means the system has expectations of you - how you are started, how data is provided and returned and how it is stopped. (There is also other stuff such as permissions and process hosting.) The canonical way of doing this is to write the service front end in Java, and then use JNI to load native code you need. But it does mean your native code needs to play well with others in the same process - something that isn't Go's sweet spot.
In your scenario there are several SSH servers available. Most are delivered as a single "app", but behind the scenes consist of an sshd binary, plus Java authored code to provide a UI (start/stop/status/configuration) and manage lifecycle.
The desire from most folk is for Go authored apps to be first class citizens, and not require using any other language. That is what is a lot of duplicate work.