4 ms·
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
by optymizer 13y ago
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!
- raganwald 13y agoIs 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?
- masklinn 13y ago> 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.
- augustl 13y agoThanks 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.
- sehugg 13y agoWhen you fork() a process you don't have to copy all process data either, thanks to copy-on-write semantics.