"EROS Mistake #3: Persistence"

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

"EROS Mistake #3: Persistence"

Post by Solar »

When I started Pro-POS almost exactly two years ago, one of the major crazes of the time was "orthogonal persistence" - people pointed to EROS, http://www.eros-os.org, and hinted at Amiga Inc. who, earlier that year, had spoken about the same thing for their to-come AmigaDE.

Today, J. S. Shapiro, chief architect, placed EROS on hold for at least a year, after posting a couple of mails to the EROS list about perceived errors in the EROS concept.
EROS Mistake #3: Persistence.

This one is *really* going to set people off. :-) I have come to the conclusion that transparent persistence is a mistake.
Back then, people called me ignorant and headstrong for not jumping at the idea. :D It's a good feeling to see at least one of my design decisions seems like it had been correct. :)

But to put an end to bragging. Have you guys thought about restartability, and how do you go about it?
Every good solution is obvious once you've found it.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:"EROS Mistake #3: Persistence"

Post by Pype.Clicker »

what is that 'persistence' idea ? can you re-explain it briefly ?
BI lazy

Re:"EROS Mistake #3: Persistence"

Post by BI lazy »

hm... BlueIllusion is coded from an engineers point of view, with very practical instead of academical considerations in mind.

So, if a process craps out due to mislead pointers, wanting to access data in no where land (see pypes commandment #1: Thou shalt not follow the null pointer), it is to vanish from the system and the programmer has to take care of getting rid of such misbehaviour- you canna grant correct function of the program anymore if it has tried such a stunt.

this orthogonal persistence thing ... whoa, what's that about ... lezz seee ...

Here is a quick definition - intellectual property: a. tanenbaum:

persistent methods have to be available to ALL types with out any action of the programmer.

all objects reachable from one object are made persistent.

There is no difference if code works with/over persistent data or not.

the ones amongst us who know the "any" data type from sybase power builder will know the sake of "unknown" datatypes - a pointer into nowhereland.

object: to be defined: is it a line in a file, an entry in some linked list, a process (no, I won't do THIS. Can't make a file a process like in EROS, that's not the way to go)?

Stay safe folks...
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:"EROS Mistake #3: Persistence"

Post by Solar »

The EROS idea was to do away with the border between in-RAM and on-disk. The system status was "persistent", i.e. after a power failure the system would restart with all the windows and data etc. just as it was. There is also no such thing as a "saved file", since the data you are working on is persistent anyway.

(At least, that's how I understood it.)

The restarting feature sure is a nice one, and I would like to know if anyone has done design work in that direction that is a bit less... well, radical. ;-)
Every good solution is obvious once you've found it.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:"EROS Mistake #3: Persistence"

Post by Candy »

Solar wrote: The restarting feature sure is a nice one, and I would like to know if anyone has done design work in that direction that is a bit less... well, radical. ;-)
I've thought about doing that and all I thought about was sending all applications something similar to a signal, telling them they were about to be stored for a long time, so the user might want to do something with the connections, and then storing the entire image (in a somewhat smart way) to the disk. Upon bootup, you load all images for the processes and send them something like a SIGWAKEUP to make them connect again.

As a sidenote, using that signal also fixes programs that use features such as clock synchronisation, or at least, makes it possible for them to fix those problems. Simplest solution in the program is to register a handler for it, and to synch all clocks to a program-based master clock. Then the master clock can be offset by as much as the real computer has slept, so the virtual clock seems to keep running for them (things like duration measurements).

I thought this approach was complete enough for it to work all the way, without hesitations.

Also, if you already have this mechanism, you might as well be able to tell the computer that a certain task is not going to be restarted in some time (such as a school report >[) so that they can be fully stored to disk.

I've also thought about using a Job-like structure, which is like the start beam in windows, but with a number of them. You can drag (move processes) between them, system keeps them all in separate job bags, and when you are busy with one job you are not hindered by all the windows that are not part of your job. Seems to me this would allow you to work a lot faster on multiple things at once (such as doing a remote gentoo linux in a remote window with some HOWTO's in your browser as 1st task, fixing OS bugs for your own OS in the second and doing your long-lost homework in the third) without being disturbed by an excessively full set of things that is active.

Come to think of it, it's similar to kde's multiple windows. Just that it doesn't require you to memorize everything that's running, or keep a strict line between the jobs...
BI lazy

Re:"EROS Mistake #3: Persistence"

Post by BI lazy »

well, I am working with some tool that faciliates object persistence of some form in the realm of transactional operations: this tool is called Siemes OpenUTM. It writes status and process information to disk for each and avery UTM process started - and in case of failure/crap out or roll back the state of the last savepoint is restored. Kinda nifty if you are to create some enterprise related very important application and want it to be transaction save.

Oracle and Informix and MS SQL Server databases for example support this kind of transactional object persistence to restore the state before failure of the actual transaction. this kind of feature is a "rollback work" - as opposed to the "Commit wORK".

but I don't think that it is task of the operating sYStem to provide this kind of transaction safe operations. If a process craps out, it is killed. period. You simply can't guarantee normal and neat behaviour of it on OS level anymore. so, away with that untrustworth thing.

stay safe...
mr. xsism

Re:"EROS Mistake #3: Persistence"

Post by mr. xsism »

I have pretty much always planned on using persistence in my Project. But i want to gie an option of a clean restart over a persistent restart. If the system becomes slow or unstable it would mostlikely remain that way with persistence.

What method would you guys use? save an memory image to file before restarting? Or would youconstantly keep an image file paraelle to memory?
Karig

Re:"EROS Mistake #3: Persistence"

Post by Karig »

I want transparent persistence in my own system, but I can imagine that this would be a massive pain if you keep trying to reload the system, only to have some misbehaving thread crash the system milliseconds after things are reloaded.

I imagine the thing to do is provide an option for the user to hold down a key while the system is booting. The system loader would check for the keypress, and if it is present, the system would load the "files" (documents, permanent data) from the partition, but not the running threads. In addition, the system loader might keep a startup log, and if the loader notices that the system keeps restarting from the same location, namely that the same threads keep being reloaded with the same state (registers, temporary data) again and again, the system loader might inform the user about the option to start up "clean," with only the "shell" thread running so the user could restart his application threads manually.
Ninjarider
Member
Member
Posts: 62
Joined: Fri Jun 29, 2007 8:36 pm

Post by Ninjarider »

it would be possible to do. you would have to have a dedicated cluster on the harddrive that you could use to put debug information for boot. it would have to be in entries. each entry would contain information in which the os could refer to each process as, time started, did it complete, any other debug information such as memory segments and stuff. the system could then on each reboot check the cluster to see if it needs to skip a process.

it could work. but its probably to much of a headache
Post Reply