Hello Nicollas and List users,
I've been monitoring and playing with neko for the past weeks, mostly
trying to understand the ocaml-inspired syntax of NekoML to create a
BASIC-like dialect.
On that subject, more documentation could be very helpful.
Yes, I know that NekoML badly need more documentation. I'm lacking time
to complete it on the Neko website.
If in the few NekoML users some want to complete the NekoML page
http://nekovm.org/doc/nekoml please click on the "Login" button bellow
in order to create a Wiki account, so you will be able to edit the pages.
Back on topic, I was asking myself how neko will provide support for
threads, using "green"-threads or native threads?
Native threads. A lot of VM that started with green threads at the
beginning have moved away from them later. Having native
threads+continuations (planned for 1.5) is a a good combinaison.
And how NekoVM will interact in that case when a native-thread (not
the one the VM is running) try to get access to the VM to change some
variable state.
Ok, hope that my question don't be too silly.
It's not silly :)
Each allocated VM it just a stack and a few variables (exception trap
pointer, tmp buffer...). You need to allocate exactly
one-VM-per-native-thread, since each thread needs a separate working
stack. But you can share a module code and global table between threads,
and use neko values allocated by another thread without any known problem.
Having several distinct VMs working in parallel and using different
values have been heavily tested. Sharing code and values between VMs
should theorically work without any problem.
The only problems might be when using some C'allocated datas in API
extensions libraries. For instance if you free the C data in a method
while the pointer is currently used in another API method called in a
separate thread, this might crash. As far as I know, most of the Neko
standard library is safe in regard to this point.
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
