I've seen macrokernels, microkernels, and even exokernels, but never a
no-kernel system (unless you count Forth). So I've been taking a look
at Genera, which is normally cited as a prime example of such a
system. But browsing the documentation and the distribution has left
me in the dark about the basic framework that allows all the objects
to interact.
Can anyone explain the facility for coordinating message passing in
Genera? Any pointers to papers or illustrative source code would also
be welcome.
From: Pascal J. Bourguignon
Subject: Re: Interprocess communication in the Symbolics OS?
Date:
Message-ID: <87ocsq1k30.fsf@galatea.local>
Wendell <·········@yahoo.com> writes:
> I've seen macrokernels, microkernels, and even exokernels, but never a
> no-kernel system (unless you count Forth). So I've been taking a look
> at Genera, which is normally cited as a prime example of such a
> system. But browsing the documentation and the distribution has left
> me in the dark about the basic framework that allows all the objects
> to interact.
>
> Can anyone explain the facility for coordinating message passing in
> Genera? Any pointers to papers or illustrative source code would also
> be welcome.
Beware, what is called process in Genera is what you would call thread
in unix. Your question is akin asking what facility there are to
coordinate message passing amongst threads in unix. Basically you
have the same means of synchronizing proceses than threads: mutexes
(called locks in zeta lisp).
http://www.softwarepreservation.org/projects/LISP/index.html#ZetaLisp_
http://www.bitsavers.org/pdf/mit/cadr/chinual_5thEd_Jan83/chinualJan83_26_Processes.pdf
--
__Pascal Bourguignon__
On Jun 14, 4:17 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Beware, what is called process in Genera is what you would call thread
> in unix.
Right. To digress, one of the things that I think was most
interesting about that architecture is how it was possible to run
multiple applications in a single address space -- multithreaded, as
you say -- without them crashing one another. (And they didn't. Lisp
Machines being used for development routinely stayed up for weeks at a
time.) The tagged architecture was very effective at preventing
memory corruption.
-- Scott
Scott Burson <········@gmail.com> writes:
> On Jun 14, 4:17 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Beware, what is called process in Genera is what you would call thread
>> in unix.
>
> Right. To digress, one of the things that I think was most
> interesting about that architecture is how it was possible to run
> multiple applications in a single address space -- multithreaded, as
> you say -- without them crashing one another. (And they didn't. Lisp
> Machines being used for development routinely stayed up for weeks at a
> time.)
Until you had to reboot for GC, right? :)
Zach
On Jun 15, 6:45 am, Scott Burson <········@gmail.com> wrote:
> Right. To digress, one of the things that I think was most
> interesting about that architecture is how it was possible to run
> multiple applications in a single address space -- multithreaded, as
> you say -- without them crashing one another. (And they didn't. Lisp
> Machines being used for development routinely stayed up for weeks at a
> time.)
I don't think this is really surprising. First of all, other shared-
address-space systems would do this as well - I used to keep emacs
instances running for weeks & weeks. Secondly, as with these other
systems, they stayed up *because you learned not to do the things that
killed them*.
I've used two Lisp machine flavours - D machines and Symbolics, and
one of the interesting things to look back on is just how random &
flaky these systems seemed when you first started using them, and then
(later) how stable they seemed (well, OK, the D machines were never
that stable, but I kept sysouts alive for weeks).
Of course it is an article of religious faith that these systems
(especially Symbolics, no one really liked the Xerox systems) were
just inherently better than anything else seen before or since
(except, of course, ITS which was better than even these systems). In
fact, I recant: no Symbolics system, in fact, ever crashed, everything
I wrote above was lies and heresy I was told to say it by a little
daemon who sits on my shoulder and whispers in my ear please do not
burn me
On Jun 15, 6:09 am, Tim Bradshaw <··········@tfeb.org> wrote:
> On Jun 15, 6:45 am, Scott Burson <········@gmail.com> wrote:
>
> > Right. To digress, one of the things that I think was most
> > interesting about that architecture is how it was possible to run
> > multiple applications in a single address space -- multithreaded, as
> > you say -- without them crashing one another. (And they didn't. Lisp
> > Machines being used for development routinely stayed up for weeks at a
> > time.)
>
> I don't think this is really surprising. First of all, other shared-
> address-space systems would do this as well - I used to keep emacs
> instances running for weeks & weeks.
I still routinely keep Emacs instances up for months -- but I don't
know if that would still be true if I were actively developing large
Emacs-Lisp systems in those instances. Mostly I'm just using code
that's already pretty much debugged.
> Secondly, as with these other
> systems, they stayed up *because you learned not to do the things that
> killed them*.
Sure there's some of that going on -- heh heh, I still remember the
time I traced FORMAT :) -- but I don't think it's just that. One
could develop code, including occasional low-level hackery, and still
keep one's single address space intact for weeks at a time.
FWIW, I don't always have the same experience developing in Common
Lisp, though maybe I just don't have as much reason not to want to
restart a CL process, since it doesn't require rebooting the whole
machine.
> Of course it is an article of religious faith that these systems
> (especially Symbolics, no one really liked the Xerox systems) were
> just inherently better than anything else seen before or since
Oh come on, that wasn't my point at all. I was just saying that I
think the tagged architecture had some value -- a value that has been
generally forgotten.
-- Scott
On Jun 15, 7:06 pm, Scott Burson <········@gmail.com> wrote:
>
> Oh come on, that wasn't my point at all. I was just saying that I
> think the tagged architecture had some value -- a value that has been
> generally forgotten.
I don't think the tagging had much to do with reliability. After all,
non-tagged architectures also check tags, they just don't do it in
hardware.
I guess what I'm claiming is that there is a lot of myth an lore
around these systems. They were reliable *when used by people who
understood them well*, and they were generally not used by people who
did not understand them well (or at least those people did not get to
contribute to the mythology). A lot of the techniques used to make
them reliable where, in retrospect, pretty nasty ("let's just stop
every other process on the machine while we do this" doesn't sound
like a great approach today). They also lived in a world where there
were few, if any, external toxins.
Don't get me wrong: they were very cool (if very expensive) systems
for their time, but their time was quite a long time ago now.
From: Frode V. Fjeld
Subject: Re: Interprocess communication in the Symbolics OS?
Date:
Message-ID: <87y6rtpqbp.fsf@disk.lan>
Tim Bradshaw <··········@tfeb.org> writes:
> I don't think this is really surprising. First of all, other
> shared- address-space systems would do this as well - I used to keep
> emacs instances running for weeks & weeks. Secondly, as with these
> other systems, they stayed up *because you learned not to do the
> things that killed them*.
But the same is to at least some extent true for systems with
protection. In, say, Microsoft Word you learn not to do certain things
if you want to keep your book manuscript, and on your desktop you
learn not to click that network disk icon unless you really want that
coffee break, and so on. It's true that my firefox process is
prevented (or at least strongly discouraged) from randomly writing
into word's address space, but if some flash animated site causes my
machine to lock up, my unsaved book manuscript is gone anyway. In a
multi-user setting, the random write is truly prevented when you have
protection, but I believe that most systems today still have a hard
time preventing e.g. denial of service attacks between users.
--
Frode V. Fjeld
······@cs.uit.no (Frode V. Fjeld) writes:
> Tim Bradshaw <··········@tfeb.org> writes:
>
>> I don't think this is really surprising. First of all, other
>> shared- address-space systems would do this as well - I used to keep
>> emacs instances running for weeks & weeks. Secondly, as with these
>> other systems, they stayed up *because you learned not to do the
>> things that killed them*.
>
> But the same is to at least some extent true for systems with
> protection. In, say, Microsoft Word you learn not to do certain things
> if you want to keep your book manuscript, and on your desktop you
> learn not to click that network disk icon unless you really want that
> coffee break, and so on.
The same is true of cars, planes, and pencils, to some extent. (Don't
take the corner at 100 if it's been raining unless you really like
doing insurance forms in a hospital bed.)
> It's true that my firefox process is prevented (or at least strongly
> discouraged) from randomly writing into word's address space, but if
> some flash animated site causes my machine to lock up, my unsaved
> book manuscript is gone anyway.
This isn't true of the system I use: I've had Firefox lock up hard and
still have been able to do other things with other running
programs. (Oh, and real editors have frequent autosaves. ;))
> In a multi-user setting, the random write is truly prevented when
> you have protection, but I believe that most systems today still
> have a hard time preventing e.g. denial of service attacks between
> users.
In all *nix systems I'm aware of (and all of them still in use), it's
possible to set per-user quotas regarding things like disk space usage
and CPU usage to effectively prevent DDoSes against other users on the
same hardware. Random writes are prevented absoutely by all modern
OSes because all modern desktop/server/mainframe hardware has MMUs.
ObOT: Did Lisp Machines tend to have MMUs? I'm pretty sure that AS/400
systems didn't/don't because the compiler (for RPG, usually) is a
trusted part of the security model and is tasked with compiling
programs that cannot possibly access memory or resources that aren't
theirs. Lisp Machines seem similar in this respect: The GC subsystem
is trusted and so is the tagging mechanism, so it would seem that no
running process ever got a hardware address it couldn't legally
dereference.
In article <··············@chbarts.motzarella.org>,
Chris Barts <··············@gmail.com> wrote:
> ObOT: Did Lisp Machines tend to have MMUs? I'm pretty sure that AS/400
> systems didn't/don't because the compiler (for RPG, usually) is a
> trusted part of the security model and is tasked with compiling
> programs that cannot possibly access memory or resources that aren't
> theirs. Lisp Machines seem similar in this respect: The GC subsystem
> is trusted and so is the tagging mechanism, so it would seem that no
> running process ever got a hardware address it couldn't legally
> dereference.
Yes, it had an MMU, but it was only needed to implement virtual memory.
There was no memory protection.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
In article <··············@chbarts.motzarella.org>,
Chris Barts <··············@gmail.com> wrote:
> In all *nix systems I'm aware of (and all of them still in use), it's
> possible to set per-user quotas regarding things like disk space usage
> and CPU usage to effectively prevent DDoSes against other users on the
> same hardware. Random writes are prevented absoutely by all modern
> OSes because all modern desktop/server/mainframe hardware has MMUs.
This stuff was implemented in servers, not in the OS itself. There's no
protection when accessing local files, but when you access files on a
file server, the server can restrict access.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Mon, 15 Jun 2009 21:56:32 -0600, <··············@gmail.com> wrote:
>
> ······@cs.uit.no (Frode V. Fjeld) writes:
>
>> It's true that my firefox process is prevented (or at least strongly
>> discouraged) from randomly writing into word's address space, but if
>> some flash animated site causes my machine to lock up, my unsaved
>> book manuscript is gone anyway.
>
> This isn't true of the system I use: I've had Firefox lock up hard and
> still have been able to do other things with other running
> programs. (Oh, and real editors have frequent autosaves. ;))
Except the autosave in MickeyMouse Word is flawed and caused system
crashes after a couple hours (something like that, I haven't turned it
on in years now). But manual saves work....but sometimes you wonder
why Billy's slave labor didn't fix those obvious crashes immediately.
Scott Burson <········@gmail.com> writes:
> Right. To digress, one of the things that I think was most
> interesting about that architecture is how it was possible to run
> multiple applications in a single address space -- multithreaded, as
> you say -- without them crashing one another. (And they didn't. Lisp
> Machines being used for development routinely stayed up for weeks at a
> time.) The tagged architecture was very effective at preventing
> memory corruption.
The Singularity OS at Microsoft Research might also be of interest.
It runs on vanilla hardware without using the MMU at all. Process
isolation is enforced statically by a type checker built into the
kernel that runs when you try to load a program. It means it's not
possible to run C programs under that OS, but Lisp is probably ok
in that Lisp values can be treated as a big union type.
On Jun 14, 4:17 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Beware, what is called process in Genera is what you would call thread
> in unix.
OK, I didn't quite grasp this before. So the entire OS plus apps runs
as a single process, with sub-components all running as threads in a
single shared address space.
That sounds like it would make life a lot harder for the programmer.
Did your approach to coding (re thread safety) have to be
significantly different on a LispM than it would be with CL on Unix?
Were there practical benefits to that architecture?
In article
<····································@x31g2000prc.googlegroups.com>,
Wendell <·········@yahoo.com> wrote:
> On Jun 14, 4:17 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Beware, what is called process in Genera is what you would call thread
> > in unix.
>
> OK, I didn't quite grasp this before. So the entire OS plus apps runs
> as a single process, with sub-components all running as threads in a
> single shared address space.
Correct.
>
> That sounds like it would make life a lot harder for the programmer.
> Did your approach to coding (re thread safety) have to be
> significantly different on a LispM than it would be with CL on Unix?
> Were there practical benefits to that architecture?
I think lots of programs didn't bother with thread safety when they
perhaps should have. Problems rarely occurred because most of the time
these data structures were only updated and accessed by the foreground
application.
Data structures that were accessed by daemons generally did get better
protection. Much of the time it was just a simple
(without-interrupts
<do something>)
There were more elaborate locking primitives, e.g. reader-writer locks;
when Symbolics started to design machines with multiple CPUs (but I
don't think the company survived long enough to bring these to market)
they started going through their code looking for places that needed to
use them.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***