Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > ruby interpreter as mach kernel server (beside bsd)

Reply
Thread Tools

ruby interpreter as mach kernel server (beside bsd)

 
 
zuzu
Guest
Posts: n/a
 
      07-08-2004
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...ingTheEnvelope

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/documenta...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/documenta...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.



 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      07-08-2004

"zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> 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?


Hm, I still don't see the advantages. As for normal Ruby programs, I
can't see any. As for access to kernel functionality, I don't see the
improvement. I guess it's my lack of understanding, so I would greatly
appreciate if anyone explains this.

Kind regards

robert

 
Reply With Quote
 
 
 
 
gabriele renzi
Guest
Posts: n/a
 
      07-08-2004
il Thu, 8 Jul 2004 17:51:36 +0900, zuzu <(E-Mail Removed)> ha
scritto::

>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").


I'll use L4:istachio wich should have become stable as of now.
I believe the guys from the Io language had the interpreter running
directly on L4, wich is a wonderful microkernel (give my little
understanding of OS theory, anyway)

 
Reply With Quote
 
zuzu
Guest
Posts: n/a
 
      07-08-2004
On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <(E-Mail Removed)> wrote:
>
> "zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
> > 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?

>
> Hm, I still don't see the advantages. As for normal Ruby programs, I
> can't see any. As for access to kernel functionality, I don't see the
> improvement. I guess it's my lack of understanding, so I would greatly
> appreciate if anyone explains this.
>
> Kind regards
>
> robert


one important aspect i have neglected to emphasize is the nature of
flow-based (aka "agent") programming style in ruby. see
http://www.jpaulmorrison.com/fbp/index.shtml


ok, here is a very concrete example i am faced with:

# given an apple dual-G5, essentailly four CPU cores are available to
process instructions in parallel.

# i am writing ruby code in the aforementioned style.
think of a beer bottling plant, where bottles move on a conveyor
through various machines: a washing machine, then a drying machine,
then a filling machine, then a capping machine, then a labeling
machine, then a packaging machine. each machine does not wait for
"all the bottles" to finish before passing the bottles onto the next
machine. each machine simply works with the bottles it has when it
has them.
in data-flow programming, the bottles are data which get
modified/transformed by each "machine" which would likely be
singletons or direct class method calls, and the conveyor belt is an
infinite stream but perceived by each "machine" as a bounded buffer.
so the *problem* becomes that several "machines" need to operate on
their buffers at the same time (in parallel).
at the same time, the user requires introspection to keep an eye on
what's happening where, and be able to make dynamic changes to the
data-flow arbitrarily.

# how can ruby utilize the 4 CPU cores for this massively parallel
bounded-buffer data-flow as a single unix process with only internal
threading?

one possible solution i thought of is to port the ruby interpreter as
a Mach microkernel server, sitting beside the bsd "personality"
server. each object would be a Mach task while each function would be
a Mach thread, and objects would communicate via Mach inter-process
communication (IPC). networking and filesystems can also be accessed
through Mach.

ruby gets the parallelization it needs, by adopting rather than
writing from scratch, an existing microkernel. in essence, a "ruby
machine".


 
Reply With Quote
 
zuzu
Guest
Posts: n/a
 
      07-08-2004
On Thu, 8 Jul 2004 16:57:24 -0400, zuzu <(E-Mail Removed)> wrote:
>
> one important aspect i have neglected to emphasize is the nature of
> flow-based (aka "agent") programming style in ruby. see
> http://www.jpaulmorrison.com/fbp/index.shtml


oops, i meant "actor"; classic mistake. http://cliki.tunes.org/Actor
http://c2.com/cgi/wiki?ActorsAndFlow...mingDiscussion


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      07-09-2004

"zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...

> On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <(E-Mail Removed)> wrote:


> one important aspect i have neglected to emphasize is the nature of
> flow-based (aka "agent") programming style in ruby. see
> http://www.jpaulmorrison.com/fbp/index.shtml


"Flow based" seems to me just another name for "event driven" from what I
read so far. It's a bit graph theory, a bit Petri Nets, a bit concurrency
theory - not nearly as sensational as the author tries to make us think.

> # how can ruby utilize the 4 CPU cores for this massively parallel
> bounded-buffer data-flow as a single unix process with only internal
> threading?


So basically what you want is, that Ruby makes use of native threads. I
guess it would be much easier to implement a Ruby interpreter that uses
native threads than to make a Mach microkernel server. And it's more
portable (i.e. POSIX threads). This sounds a bit like the wrong hammer to
your problem. But then again, I'm not a microkernel expert.

> one possible solution i thought of is to port the ruby interpreter as
> a Mach microkernel server, sitting beside the bsd "personality"
> server. each object would be a Mach task while each function would be
> a Mach thread, and objects would communicate via Mach inter-process
> communication (IPC). networking and filesystems can also be accessed
> through Mach.


IMHO making each object a mach task would be overkill. You probably meant
each *component* (i.e. independent self contained processing unit as
described by Paul Morrison) should be a mach task.

Regards

robert


PS: Attached some sample of what I understand from "flow based".

 
Reply With Quote
 
zuzu
Guest
Posts: n/a
 
      07-09-2004
On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <(E-Mail Removed)> wrote:
>
> "zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
>
> > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <(E-Mail Removed)> wrote:

>
> > one important aspect i have neglected to emphasize is the nature of
> > flow-based (aka "agent") programming style in ruby. see
> > http://www.jpaulmorrison.com/fbp/index.shtml

>
> "Flow based" seems to me just another name for "event driven" from what I
> read so far. It's a bit graph theory, a bit Petri Nets, a bit concurrency
> theory - not nearly as sensational as the author tries to make us think.


word on graph & concurrency theory, reading up on petri nets now
(wikipedia)... (also reminds me to finish reading 'Linked' by ALB.)

perhaps there's something better for me to read up on event driven
programming besides [http://c2.com/cgi/wiki?EventDrivenProgramming],
but it sounds much earlier in the evolution of an idea.

> > # how can ruby utilize the 4 CPU cores for this massively parallel
> > bounded-buffer data-flow as a single unix process with only internal
> > threading?

>
> So basically what you want is, that Ruby makes use of native threads. I
> guess it would be much easier to implement a Ruby interpreter that uses
> native threads than to make a Mach microkernel server. And it's more
> portable (i.e. POSIX threads). This sounds a bit like the wrong hammer to
> your problem. But then again, I'm not a microkernel expert.


maybe i'm nitpicking, but i feel a problem exists that processes, not
threads, are necessary. when the parent process dies (perhaps because
of a bad thread), all of its threads go with it. this is a problem
when one small error causes my entire application to crash. (one
small error in one object in my web browser should not lose me all of
my "unsaved" rendered pages and URL information with it. just that
one faulty object should die and get respawned.) maintaining my human
productivity with persistent objects is more valuable than the
footprint of many processes. O(1) schedulers make "too many
processes" a moot point in a cheap hardware world anyway, methinks.

> > one possible solution i thought of is to port the ruby interpreter as
> > a Mach microkernel server, sitting beside the bsd "personality"
> > server. each object would be a Mach task while each function would be
> > a Mach thread, and objects would communicate via Mach inter-process
> > communication (IPC). networking and filesystems can also be accessed
> > through Mach.

>
> IMHO making each object a mach task would be overkill. You probably meant
> each *component* (i.e. independent self contained processing unit as
> described by Paul Morrison) should be a mach task.


you do not think that paul's "components" essentially map directly to
ruby "objects"?

> Regards
>
> robert
>
>
> PS: Attached some sample of what I understand from "flow based".


word, i'll give it a serious look this weekend.

-z


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      07-09-2004

"zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <(E-Mail Removed)>

wrote:
> >
> > "zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
> > news:(E-Mail Removed)...
> >
> > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <(E-Mail Removed)>

wrote:
> >
> > > one important aspect i have neglected to emphasize is the nature of
> > > flow-based (aka "agent") programming style in ruby. see
> > > http://www.jpaulmorrison.com/fbp/index.shtml

> >
> > "Flow based" seems to me just another name for "event driven" from

what I
> > read so far. It's a bit graph theory, a bit Petri Nets, a bit

concurrency
> > theory - not nearly as sensational as the author tries to make us

think.
>
> word on graph & concurrency theory, reading up on petri nets now
> (wikipedia)... (also reminds me to finish reading 'Linked' by ALB.)


)

> perhaps there's something better for me to read up on event driven
> programming besides [http://c2.com/cgi/wiki?EventDrivenProgramming],
> but it sounds much earlier in the evolution of an idea.


I think in the telco world this is quite ubiquituous. SDL is used to
design such scenarions (communicating proceses) and SDL is widely used in
that area AFAIK.

> > > # how can ruby utilize the 4 CPU cores for this massively parallel
> > > bounded-buffer data-flow as a single unix process with only internal
> > > threading?

> >
> > So basically what you want is, that Ruby makes use of native threads.

I
> > guess it would be much easier to implement a Ruby interpreter that

uses
> > native threads than to make a Mach microkernel server. And it's more
> > portable (i.e. POSIX threads). This sounds a bit like the wrong

hammer to
> > your problem. But then again, I'm not a microkernel expert.

>
> maybe i'm nitpicking, but i feel a problem exists that processes, not
> threads, are necessary. when the parent process dies (perhaps because
> of a bad thread), all of its threads go with it. this is a problem
> when one small error causes my entire application to crash. (one
> small error in one object in my web browser should not lose me all of
> my "unsaved" rendered pages and URL information with it. just that
> one faulty object should die and get respawned.) maintaining my human
> productivity with persistent objects is more valuable than the
> footprint of many processes. O(1) schedulers make "too many
> processes" a moot point in a cheap hardware world anyway, methinks.


Well, normally a dying Ruby thread does not kill the whole process.
Whether multiple processes or threads is not the major point. The major
point is that you need concurrency for flow based programs to happen, not
a kernel integration. The kernel integration might be a means but it
looks inappropriate to me.

> > > one possible solution i thought of is to port the ruby interpreter

as
> > > a Mach microkernel server, sitting beside the bsd "personality"
> > > server. each object would be a Mach task while each function would

be
> > > a Mach thread, and objects would communicate via Mach inter-process
> > > communication (IPC). networking and filesystems can also be

accessed
> > > through Mach.

> >
> > IMHO making each object a mach task would be overkill. You probably

meant
> > each *component* (i.e. independent self contained processing unit as
> > described by Paul Morrison) should be a mach task.

>
> you do not think that paul's "components" essentially map directly to
> ruby "objects"?


Exactly.

> > Regards
> >
> > robert
> >
> >
> > PS: Attached some sample of what I understand from "flow based".

>
> word, i'll give it a serious look this weekend.


Don't look to hard. I guess it's not overly well designed. Just to get
the picture. Basically a processor has an incoming queue which is dealt
with by a thread. Processing can be anything from printing to sending
something to an attached processor. Concurrency saftety is ensured be the
queues. That's about it.

Regards

robert

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
 
Reply With Quote
 
zuzu
Guest
Posts: n/a
 
      07-09-2004
On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <(E-Mail Removed)> wrote:
>
> "zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:(E-Mail Removed)...
> > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <(E-Mail Removed)>

> wrote:
> > >
> > > "zuzu" <(E-Mail Removed)> schrieb im Newsbeitrag
> > > news:(E-Mail Removed)...
> > >
> > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <(E-Mail Removed)>

> wrote:
> > >
> > > > one important aspect i have neglected to emphasize is the nature of
> > > > flow-based (aka "agent") programming style in ruby. see
> > > > http://www.jpaulmorrison.com/fbp/index.shtml
> > >
> > > "Flow based" seems to me just another name for "event driven" from

> what I
> > > read so far. It's a bit graph theory, a bit Petri Nets, a bit

> concurrency
> > > theory - not nearly as sensational as the author tries to make us

> think.
> >
> > word on graph & concurrency theory, reading up on petri nets now
> > (wikipedia)... (also reminds me to finish reading 'Linked' by ALB.)

>
> )
>
> > perhaps there's something better for me to read up on event driven
> > programming besides [http://c2.com/cgi/wiki?EventDrivenProgramming],
> > but it sounds much earlier in the evolution of an idea.

>
> I think in the telco world this is quite ubiquituous. SDL is used to
> design such scenarions (communicating proceses) and SDL is widely used in
> that area AFAIK.


word, i think i've heard that before. if i think of the specific
context i'll post it.

> > > > # how can ruby utilize the 4 CPU cores for this massively parallel
> > > > bounded-buffer data-flow as a single unix process with only internal
> > > > threading?
> > >
> > > So basically what you want is, that Ruby makes use of native threads.

> I
> > > guess it would be much easier to implement a Ruby interpreter that

> uses
> > > native threads than to make a Mach microkernel server. And it's more
> > > portable (i.e. POSIX threads). This sounds a bit like the wrong

> hammer to
> > > your problem. But then again, I'm not a microkernel expert.

> >
> > maybe i'm nitpicking, but i feel a problem exists that processes, not
> > threads, are necessary. when the parent process dies (perhaps because
> > of a bad thread), all of its threads go with it. this is a problem
> > when one small error causes my entire application to crash. (one
> > small error in one object in my web browser should not lose me all of
> > my "unsaved" rendered pages and URL information with it. just that
> > one faulty object should die and get respawned.) maintaining my human
> > productivity with persistent objects is more valuable than the
> > footprint of many processes. O(1) schedulers make "too many
> > processes" a moot point in a cheap hardware world anyway, methinks.

>
> Well, normally a dying Ruby thread does not kill the whole process.
> Whether multiple processes or threads is not the major point. The major
> point is that you need concurrency for flow based programs to happen, not
> a kernel integration. The kernel integration might be a means but it
> looks inappropriate to me.


but processes never corrupt/crash other processes, except in the event
of a kernel panic, correct? however much debate exists over the
safety of threads. though pan-unix compatability would be much more
popular than a mach kernel implementation (which basically means apple
xnu and gnu/hurd).

http://c2.com/cgi/wiki?ThreadsConsideredHarmful

" Some tasks may be truly independent; having independent simultaneous
flows of control is useful.
* But: Separate processes may be a better solution.
o On some OS's (ie Windows) that is much more expensive than
separate threads (on Unix derivatives, separate processes are much
cheaper)"

and according to john carmack writing quake 3:
# avoid threads if possible
# if you have to have threads, then have only one per CPU
# avoid threads if possible
# share as little data as possible between threads
# are you sure a separate process with shared memory or other IPC wouldn't do?

i think inter-process communication (IPC) is more preferable as well.
(though i'm open to discussing the semantical differences.)

i believe i am asking this same question:
"I would reply to GlenStampoultzis with a question of my own: why use
threads at all if you isolate the parts of your program properly?
Processes with message passing could do just as well, no? --
PierrePhaneuf"

> > > > one possible solution i thought of is to port the ruby interpreter

> as
> > > > a Mach microkernel server, sitting beside the bsd "personality"
> > > > server. each object would be a Mach task while each function would

> be
> > > > a Mach thread, and objects would communicate via Mach inter-process
> > > > communication (IPC). networking and filesystems can also be

> accessed
> > > > through Mach.
> > >
> > > IMHO making each object a mach task would be overkill. You probably

> meant
> > > each *component* (i.e. independent self contained processing unit as
> > > described by Paul Morrison) should be a mach task.

> >
> > you do not think that paul's "components" essentially map directly to
> > ruby "objects"?

>
> Exactly.


hehe, um, because...?

> > > Regards
> > >
> > > robert
> > >
> > >
> > > PS: Attached some sample of what I understand from "flow based".

> >
> > word, i'll give it a serious look this weekend.

>
> Don't look to hard. I guess it's not overly well designed. Just to get
> the picture. Basically a processor has an incoming queue which is dealt
> with by a thread. Processing can be anything from printing to sending
> something to an attached processor. Concurrency saftety is ensured be the
> queues. That's about it.
>
> Regards
>
> robert
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel#autoload ignores custom monkey patched Kernel#require Lars Gierth Ruby 6 03-20-2010 10:35 PM
Why "Kernel.puts" and not "Kernel.put"? shadytrees@gmail.com Ruby 3 04-08-2006 01:42 PM
kernel hangs after "UNCOMPRESSING KERNEL OK BOOTING KERNEL" yogesh C Programming 3 02-12-2006 11:19 AM
Mach TA VHDL_lover VHDL 0 02-08-2005 02:57 AM
info wanted on how to make a mail server on ms xp home mach goneill NZ Computing 11 08-08-2003 10:59 AM



Advertisments