hanez

We don’t expose shared mutability to VMs. The trick is: publish‑as‑immutable plus adoption via ports. Ports/queues do the synchronization; fun_shared_buffer is off‑heap and refcounted with atomic ops. The host doesn’t need to lock anything for the common paths.

• We default to isolates for safety and scaling.

• Zero‑copy sharing is done with fun_shared_buffer, an off‑heap, GC‑untracked, pointer‑free block that’s immutable from the VM’s point of view.

• Lifetime is managed with plain reference counting (retain/release).

• For hot paths, we also support an adoption (ownership‑transfer) pattern during message passing so the sender can drop its ref without copying.

• Yes: isolated state (one VM per embed) is usually the right default. It avoids global locks (e.g., a GIL), makes scheduling simpler, and keeps failure/lifetime boundaries crisp.

• Yes: shared‑memory primitives are the “escape hatch” for when copying/serialization is too expensive, but they should be very carefully constrained.

• GC: If you design shared regions to be untraced (no VM heap pointers inside), each VM’s GC can remain independent and never stop other VMs. If you allow GC’d objects to be shared across VMs, you either need a global safepoint (stop‑the‑world across participants) or a more complex concurrent/barriered scheme.

I added some more information about this to the internals document.

I need to say, that issues can be opened at https://github.com/hanez/fun/issues, but I do not develop Fun on GitHub. Pull requests will not be accepted there. Send patches or ask me for an account on https://git.xw3.org... ;)

I added a section to https://git.xw3.org/fun/fun/src/branch/main/docs/internals.m... that describes this more detailed. I copied from other documents some seconds ago and I am not sure if this all is 100% correct actually. I will check this and will update the file if I find some wrong parts...

I chose isolated state (like Lua) rather than a single global lock (like Python’s GIL). Each VM has its own heap, scheduler, and garbage collection. There are no cross-VM pointers. Concurrency and data exchange happen via message passing and a few carefully scoped shared-memory primitives for high‑throughput use cases. This keeps the C API simple, predictable, and safe to embed in multi‑threaded hosts.

You're welcome! Would love to get some feedback!

What is Fun?

Fun is an experiment, just for fun, but Fun works!

Fun is a highly strict programming language, but also highly simple. It looks like Python (My favorite language), but there are differences.

Influenced by Bash, C, Lua, PHP, Python, and a little Rust.

Fun is written in C(C99) and many libs are implemented in pure Fun. Smartcard(PCSC) is available as extension written in C while sha256 or sha512 are implemented in Fun.

Would love to get some feedback (hanez@fun-lang.xyz), but please read the content on https://fun-lang.xyz first.

Have fun! hanez

Uh, he ist not a bot, he is not a bot, he is not a bot... :D

That clarified the difference! Thank you.

I think I mixed rump kernel and rumprun. I saw a talk long time ago and am not very deep into that nowadays.

Therefore, double thanks!

Exactly this is what the original post is about... ;)

I believe to get this production ready will take some years.

From what I understand in the projects FAQ page they want to implement the concept of a Unikernel and this is what the Rump Kernel at http://rumpkernel.org/ is intending too. May I am wrong because I am not to deep into it.

If it is a research project then they should go on... It looks like it is because it is beeing developed at a university in Oslo, Norway. http://www.hioa.no/eng/

What they want to do is to implement the concept of a unikernel (https://en.wikipedia.org/wiki/Unikernel). That's a very different approach then running a complete OS with their software stack on top. Take a look at the two links in my other comment.

Sounds a little bit crazy to me at first but when thinking about it, it is a nice idea.

May you should take a look at Rump Kernels and build your stuff on top. Then you do not need to implement the OS stuff - It's done already. May I am wrong but it seems to be a similiar idea but the following project is currently at the OS level only but some applications like ngnix are working already. I was very confused when I first read about Rump Kernels and after reading a while and watching some conference talks a lot of stuff made sense to me even if I do not understand in detail what they are doing.

http://rumpkernel.org/

https://github.com/rumpkernel

Yes, I am aware of that but I wanted to understand the usage of 'look' at this point. It was a fault to try stuff using the .zshrc file at first because I ran into misunderstanding everything. It was just the first file that came in mind to me. Since sorting a source file and then "looking" for comments makes no sense in any way, grep seems to be really the better choice.

Uh, wow! That was it!

Thanks for this answer...

When sorting the file first I get no output anymore:

sort ~/.zshrc -o /tmp/.zshrc

look "#" /tmp/.zshrc

Sorry for the noise but I am confused... :|

When running 'look' to get all comments in a file I only get the first found line in the ouput. Can someone explain this?

look "#" .zshrc

There are really a lot more comments (lines starting with '#') in my .zshrc then the first line.