From: zuzu <sean.zuzu@...>
Date: 2004-07-08T17:51:36+09:00
Subject: ruby interpreter as mach kernel server (beside bsd)

ruby, starting the interactive ruby shell, but with filesystem access
to unix/bsd through the mach microkernel.  in other words, a "ruby
machine" (instead of a "smalltalk machine" or "lisp machine").

what do you think?


7/7/2004 11:37 PM
http://www.jpaulmorrison.com/cgi-bin/wiki.pl?PushingTheEnvelope

so... in trying to solve the "ruby space" problem, i've been thought
experimenting with the what-if of the ruby interpreter / runtime
environment as a kernel server in parallel to a unix "personality"
server under the mach microkernel.

unlike the design of GNU/hurd, most microkernel unix operating systems
implement Mach for the basics (multi-tasking/processes, threads,
multi-processor on single machine or over a network, inter-process
communication / IPC, memory protection) and then a single "unix kernel
server" to fill out the rest of the unix functionality found in
monolithic kernels such as linux.

so if the ruby interpreter were another "kernel server" parallel to
the "unix kernel server", ruby would still interact with the
traditional unix environment, but each object in "ruby space" could be
its own process (as compiled C utilities are in traditional unix) for
truely reuseable and fault-resistent components. (this essentially
creates a virtual "ruby machine" not unlike "smalltalk machines" and
"lisp machines" of yore.)

the reason i mention such a wild idea here, other than continuing the
discourse on threads and processes, is because of how similar the Mach
design feels compared to flow-based programming FBP:

1. object-based APIs with communication channels (for example,
*ports*) as object references
2. highly parallel execution, including preemptively scheduled threads
and support for SMP
3. a flexible scheduling framework, with support for real-time usage
4. a complete set of IPC primitives, including messaging, RPC,
(a)synchronization, and notification
5. support for large virtual address spaces, shared memory regions,
and memory objects backed by persistent store
6. proven extensibility and portability, for example across
instruction set architectures and in distributed environments
7. security and resource management as a fundamental principle of
design; all resources are virtualized

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Mach/chapter_6_section_1.html

it's almost as if the Mach kernel just needs a friendly interface to
running code through it, and ruby could very well be that friendly
syntactic sugar.

of course this grossly underestimates the difficulty of writing kernel
software, particularly for a microkernel such as Mach. paul, your
expertise seems very C heavy, perhaps you have a better gague of
approachability.
  	

7/8/2004 12:26 AM
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Mach/chapter_6_section_3.html

A thread

* is a point of control flow in a task.
* has access to all of the elements of the containing task.
* executes (potentially) in parallel with other threads, even threads
within the same task.
* has minimal state information for low overhead.

A task

* is a collection of system resources. These resources, with the
exception of the address space, are referenced by ports. These
resources may be shared with other tasks if rights to the ports are so
distributed.
* provides a large, potentially sparse address space, referenced by
virtual address. Portions of this space may be shared through
inheritance or external memory management.
* contains some number of threads.

Note that a task has no life of its own—only threads execute
instructions. When it is said that "task Y does X," what is really
meant is that "a thread contained within task Y does X."


to me, this sounds as though in ruby, a task would map to an object,
and a thread to a function.