Rethinking the guest operating system

Posted Sep 19, 2013 10:32 UTC (Thu) by lacos (guest, #70616)
In reply to: Rethinking the guest operating system by aleXXX
Parent article: Rethinking the guest operating system

> What happens if I fork() ?

This is addressed in the presentation linked in the article, slides 38-39:

> Porting a C application to OSv
> [...]
> 2. May not fork() or exec()

Rethinking the guest operating system

Posted Sep 19, 2013 23:33 UTC (Thu) by Karellen (subscriber, #67644) [Link] (2 responses)

Hmmm....given that the mechanics behind fork() aren't that much different from pthread_create() (Linux clone() system call) - any idea if that means no threads also? (Slides were unclear on that point)

If not, not only does that get in the way of explitly multi-threaded apps, but surely it also suddenly hobbles functional languages which offer the promise of great scalability performance using transparent parallelism over many threads (e.g. for operations like map/reduce) on todays multi-core systems?

Won't converting those apps to not just multi-process, but multi-(virtual)-machine, systems make them a heck of a lot *worse* than they are now?

Or was this mostly build to run bloody Java?

Rethinking the guest operating system

Posted Sep 20, 2013 0:44 UTC (Fri) by dlang (guest, #313) [Link]

> Or was this mostly build to run bloody Java?

As I read it, it was built _only_ to run Java

Rethinking the guest operating system

Posted Sep 20, 2013 5:01 UTC (Fri) by glommer (guest, #15592) [Link]

We support threads just fine. The limitation behind fork is not due to parallelism, but about the address space isolation.

About the whole java thing, I have written a G+ post to clear that up:
https://plus.google.com/107787008629542080430/posts/cx4Ro...

We are Java focused, not java only.