On GUIs and such things

[Kragen Sitaker]

Shawn T. Rutledge writes:
> > EROS' approach is to isolate corruption within a single domain and
> > memory leaks within the children of a single spacebank.
> 
> That's good, but a leak is still a leak if you never shutdown the 
> program and restart it, but just persist the entire running state.
> Not that it's a bad idea, but it imposes more rigor on the quality
> of the software.

Only the software that never gets shut down and restarted.  Jonathan wrote:

> Neither of these statements is relevant to persistence in EROS. The problem
> is that this statement is mixing a couple of levels of abstraction.
> 
> For purposes of understanding persistence, the only code we care about in
> EROS is the kernel. If a domain is bad, EROS will guarantee that it is still
> bad on reboot.

The point of Shawn's statement, I think, is that memory leaks can
continue across reboots, which they can't in OSes that don't support
transparent persistence.

I think very little software should run forever, which solves the
problem.

> > > It would be best to exclusively use languages which prevent these 
> > > problems.
> > 
> > Those languages have their own problems ;)
> 
> Performance?  the usual complaint.  What other problems?  (BTW when
> I said "exclusively" I meant for user-level applications...not the OS)

High-level languages have some disadvantages, but I don't think
poor performance is legitimately among them.

Unpredictable performance and resource usage were what I was thinking
of.  

In a program doing slightly complicated dynamic allocation and
deallocation, garbage collection is far more likely to be correct than
manual free(), and is quite likely to make the program faster; however,
once you have gotten manual free() right, you can probably predict your
program's storage usage correctly with a significant amount of extra
effort.  Doing it in a GCed system is as much work as getting manual
free() right.

In general, if you care a lot about your program not ceasing to run,
you care whether it has enough space to keep running.  This means you
have to know how much space that is.

Furthermore, if your program needs to do something in particular if it
doesn't have enough space to keep running, you need to express that
something in such a way that you can verify that it won't require any
*extra* space.  The big benefit of GC is that things you call can
transparently allocate things and return them to you.  You don't want
them to do that in this situation.

Unpredictable performance: real-time programs need to be guaranteed to
complete certain tasks within certain time bounds.  Garbage collection
--- indeed, dynamic allocation in general --- can make this tough.  But
so can many other features of high-level languages.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves        
possess.
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]