

LuaJIT on Xen - justincormack
http://www.freelists.org/post/luajit/LuaJIT-on-Xen

======
justincormack
The framework here is fairly general and you should be able to run other code
directly under Xen eg Python. Node would be harder as there is no threading
which libuv needs.

~~~
anttiok
There is threading in the underlying framework. In fact, since there is no VM
support, threading is all you have.

However, there is no pthread support which is probably what you are referring
to. I don't think pthread support would be difficult to add. Most likely it's
trivial in case non-preemptive run-to-block threads are ok. If someone has a
use case for pthreads, I'm up for a discussion.

~~~
justincormack
Libuv which node.js uses has threads to do non blocking file IO. Haven't
looked at the code for ages though so not sure exactly what it needs.

~~~
gcr
Is this because asynchronous I/O calls don't work consistently well on all the
platforms that libuv targets?

~~~
justincormack
Async file IO on Linux is a bit odd, although it is gradually getting better.
It only applies to unbuffered IO (I think still). So you have to use a thread
to read or write. Windows has a more usable version. There is a Unix standard
API but it is just implemented with threads normally anyway.

------
silentOpen
OCaml on Xen [http://www.openmirage.org/](http://www.openmirage.org/)

------
mwcampbell
What advantage is there to running something like this on Xen rather than
running an almost equally self-contained process on a general-purpose OS
kernel like Linux or BSD? Is Xen's resource isolation that much better?

~~~
zhemao
Perhaps not, but I think the purpose of these Xen exokernels is to run on IaaS
platforms which provide Xen VPS, like EC2 or Linode.

------
keeblus
The limitations seem pretty high. Why would I use this when I could run
something like Docker on bare metal?

~~~
justincormack
Docker is a way of making config management easy. Here there really is less
stuff. You build a binary with your whole application and all its dependencies
that actually self hosts. And is smaller than Docker's init process.

And a VM is better isolated than a Linux container.

EDIT: the restrictions are not necessarily permanent either. Its only a first
early release...

~~~
anttiok
Yes, tiny resource overhead while still providing near-complete isolation is a
big benefit. The current memory overhead from using file system drivers and
TCP/IP networking is around 8MB, and I'm sure there's a bunch of fat in there
that could be trimmed off.

It's going to be interesting to see where the exact set of supported
application images converges as use cases arise. For example, I'm pretty sure
fork() will never be supported -- would it fork the VM? -- but some of the
other things are up for discussion.

