Martin: good to see you here! On Tue, 2005-11-08 at 00:00 +0100, Martin Schoenbeck wrote: > It was mentioned here, being unable to cure a hanging program by reboot, > was one of the disadvantages of persistence. That's true, but if you do > a reboot with conventional systems, you loose the context of most of > your programs and for those programs, which remember the context, *you* > must remember, to start them again. I'm regurlarly loose several open > browser windows with not yet read contents in such situations.
Yes. I also wanted to respond to this point. If a program is hung, you should be able to kill it. Rebooting is kind of like using a nuclear bomb to open the bedroom door when it is humid and the wood has swelled very slightly. This, of course, is not true for critical system programs at the level of things like the storage allocator. In EROS (and, I suspect, in Eumel; can you comment, Martin?) these programs are extremely simple and VERY carefully designed. Fortunately there are very few programs where this degree of care is required. Ironically, it is the *presence* of persistence that allows these programs to be simple. Think, for a moment, about a conventional (ad-hoc persistent) file system. You have two basically simple issues (space allocation, file structure management) that are intertwined with an ad-hoc transaction processing system (in order to ensure consistency). The need for consistent I/O makes things complicated, but also slow, so next you make the file system concurrent, which compounds the problem of complexity by several orders of magnitude. Next, you decide that waiting for all of the disk writes is slow and highly synchronizing, so you migrate some of the burden into fsck. This lets you do fewer synchronizing I/O operations, but at the cost of making the relaxed I/O ordering invariants *extremely* complicated to maintain. I just ran my lines of code tool on parts of the linux-2.6.12.4 source tree. The Linux fs/ext3 directory alone contains 10,447 NCLOCS, and this code does NOT include argument processing. fs/reiserfs is 18,534 lines. Hell, guys, the entire EROS *microkernel* is only 21,563 NCLOCS (excluding kernel debugger). For comparison, the EROS file server implementation contains 498 NCLOCS (non-comment, non-blank lines of code). The directory implementation is another 418 NCLOCS. These counts **include** the IPC message processing. They do no synchronous I/O, and therefore have no need to be multithreaded. I would bet that the Eumel file system is not very much different in its complexity. Antrik: earlier I was a bit impatient with your assumptions about the complexity of orthogonal persistence, and I probably should apologize. Now that you see the actual numbers and some of their consequences, does the argument in favor of persistence at least seem a little clearer? In my opinion, if this result was the *only* benefit of persistence, it would probably be worthwhile. Martin: how are similar things handled in L3/Eumel, and do you see similar complexity reduction in these very critical pieces of code? shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
