"Imagine it's 2006. For a monthly fee, AOL Time Warner's cable subsidiary delivers a service finely tuned to your interests. One night after work, you sink into the couch. After scrolling through a few pages of Snow Crash on your E-Book reader, you switch on your TV with its Web-enabled set-top box to download Neal Stephenson's latest work. You spin a free live cut from the ongoing Radiohead reunion tour, close the annoying pop-up box that invites you to buy the entire concert for $4.99, and then drop by IMDb.com to look into your latest cinematic obsession: directorial pioneer D. W. Griffith. Maker of 555 movies, Griffith hasn't premiered a new film in more than half a century. AOL, however, liberated from the overheads of manufacturing, warehousing, and shipping, can profit by offering subscribers his entire oeuvre.."

Digital convergence seems to be the latest buzzword. Given, buzzwords don't have a great track record (*ahem* internet appliance *ahem*). I think that this one, though, has a lot of potential *IF* it is not executed ahead of its time.

I spent a good part of my afternoon unpacking books from storage - some I had not read in 10 years since they were placed into storage. I had a lot of time to reflect on the nature of the medium. Paper has been around for thousands of years. It is portable, requires no power, and can be used for any number of emergency uses, from fire building to blowing your nose, but it has negatives, too. It is heavy, dusty, it yellows, and it is not searchable, editable or amenable to notations. If I had every one of my books available as an E-Book, I would have far more space. I could have copied and pasted that Wired article instead of retyping the whole thing. I could access any of my books at will without moving to the shelves. I could lend them and know that I will get them back.

OK, books aren't that tough of a medium to deal with. Let's take music. I have ripped almost every one of my CDs to MP3. I have them all on my computer here in my office. I have MP3 CDs at work, so I can jam to my tunes wherever I am. I could theoretically make them available via Internet so that wherever I am I could get to them.

Look at what Tivo has done for television watching. I would love to have what I would consider to be good TV available any time I choose. Why do I stay up until 1AM to catch Star Trek:TNG reruns? Why is Fox in charge of my life? They own the episodes.

The magic answer for convergence would need to store data - basically, a file server that keeps all of my books, movies, TV, music, etc. It would serve it to me anywhere that I am at any time, could detect me and be fraud proof. It would serve the files in the format that I need them. If I were at my computer, it could send me MP3's or .divx movies. At the TV? It would transmit the video and sound in real time. Maybe even answer my phone, handle faxes, pull pages from the internet the same way that Tivo works from TV, and more.

How can we reconcile the simplicity of kernel concepts with the apparent difficulty of making them? Simply thus: in building a kernel, you have to write nearly perfect code. It is the one place where ugliness is (sometimes) allowed for efficiency's sake. Goto is sometimes used in kernels. Typecasting of void pointers is used. C++ is often times not used. Breaking functions into pieces is sometimes not done because the overhead (either in time or in stack space) is detrimental. It is the last real haven for the bare metal, elite asm coder.

The single largest piece of source code in NewOS is its threading system at > 45k. It is also one of the most critical subsystems.

A process in NewOS is little more than a name, an addess space, and a list of threads. Processes have no concept of execution. They don't really run - they just exist as structures in kernel memory. What the process does have, though, is a "main" thread. This thread is created at process creation time. When the kernel loads an ELF executable, this is the thread that starts the code. This thread can, of course, make more threads. When the main thread dies, all of the other threads are killed.

Threads have many of the attributes that are classically assigned to processes in, say, more Unix-like operating systems. They have a name, an id (tid), a priority, a state, a "next state", pending signals, and much more.

    thread:
        name
        id
        priority
        state
        next state
        pending signals
        ...

A thread is run by changing its state to "running", setting a timer to interrupt the processor after a while (pre-emptive multitasking), and setting the processor to user mode at the address where the thread left off. There are, of course, more details (like restoring the registers, etc), but this is the concept.

The Next State is almost like the return code of a function. It is an indicator to the kernel what should be done with this thread the next time around. Was the thread still running? Did it block because it tried to allocate a resource? Did it end? The kernel queues that thread into the proper queue and starts up the next one in the ready-to-run list.

All good things must come to an end. Eventually, (almost) all threads are ended. There is a function in the kernel for this (thread_exit). The user stack space is freed. The thread is removed from the user process and added to the kernel process for the duration of its demise. Even though it might seem so, this is not a security risk because the thread can not be scheduled to run. If this thread is the main thread, the other threads are deleted.

A death stack is allocated. Normal threads have the user stack and the kernel stack. The user stack is used by the user process for function calls, local variables, etc and the kernel stack is used by the kernel for its function calls, etc when the thread is using kernel-level services. A problem comes near the end of the thread's death, when the kernel stack needs to be released, but some functions and such need to be called.

The solution is to make a death stack - a statically-allocated stack that the kernel assigns to the thread as it dies. The final cleanup of the thread occurs - its name is freed, it is removed from the process, it is removed from the global thread list, and then it is ready to actually be freed. The mechanism for this is the Next State. There is a Next State that means to die on reschedule. The kernel scheduler is handed control, which sees that the Next State is set to delete on reschedule and deletes it.