Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This idea reminds me of what Go is doing with their channels to solve concurrency issues: they're essentially sharing data by copying the data.

Copying data is slow and that's why Go's channels aren't the fastest solution, but they're less complex than dealing with the traditional concurrency issues.

I've written a toy kernel and I just can't imagine copying all process data because 1 little thing changed. However, there's no reason not to pursue this idea, as it may prove to be useful in certain cases. If real-time schedulers have their place, why wouldn't such an OS have its uses? I think Go (and other projects) have proved the concept works, so maybe it's time to see an OS?

Best of luck to you and I hope to hear good news in the future!



> they're essentially sharing data by copying the data.

No. Go only copies the immediate values, if you send a pointer the pointee is shared for instance. Go's concurrency is shared-memory.

Erlang copies (almost[0]) the data sent between processes, and has process-local heaps.

[0] binaries above 64 bytes (IIRC) are refcounted and shared.


Thanks a lot :) I cannot imagine that the web will ever work on this OS.. How do you implement a mutable system (JavaScript) with an immutable core? So it's definitely not for everyone.


Is it copying all process data? Or copying a reference to the process data and then performing copy-on-write when a process makes changes locally?


When you fork() a process you don't have to copy all process data either, thanks to copy-on-write semantics.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: