Asynchronous Callback
I'm back, but in a pretty weird capacity. I was reading through the old Chronicles, and decided that, in all probability, nobody understood the computer science references I made during my last few Chronicles.
That sounds pretty pretentious and arrogant. I can't assure you that its not, but that's kind of the only way I can get it across.
My mind, then and probably moreso now, operates on the desolate edge of obscurity, with references between what I write and the real world being so tenuous and tedious that they can only be explained and understood at great length. This occurs as well for me in other situations: specifically, in everything else. In other words: losing my grasp on reality. Also: going crazy.
And thus the purpose of this returning Chronicle. I feel that in making these ridiculous references that I'm doing the reader a disservice, forcing them to ignore certain parts to avoid traversing a steep learning curve. I also feel that unless I explain what I mean, particularly in the process of my writing, then my meaning will be lost, to myself as well as those reading.
So here are the references I've made, either in the body of the articles or the titles, with what I feel to be an adequate explanation of their meaning and their intention in including them.
return 0;
---------
The C programming language has a long, long history. In fact, I might go so far as to say that its usage and development reflect and possibly affect the usage and development of computers since the language's inception.
One particular piece of its history I find somewhat interesting regarding how C programs affected operating systems. Operating systems used to care a lot more about the programs that they were running. This was because people used to care a lot more about what programs they were running, considering it took considerable and expensive hardware to run even a small number of programs. But those people who cared about what they were running knew a lot more about the systems they worked on, how they were built, and who built them. And at one time, everybody who knew anything about computers knew C.
Also, initially, all variants of Unix were built with the C programming language. In turn, they expected the programs that their operating systems were to run should follow some of the programming schemes of C. One such scheme was how a C program was expected to end.
In the beginning, C required every program to return an integer. Based on that integer, one could determine the final state of the program, that is, whether it ran successfully, or if the program itself was part of a larger script, then to give the calling script a flag based on that integer.
If a program returned an integer 0, then it returned successfully. If a program returned anything but 0, then it was considered to have ended in an error state. If this error state was not detected by a script, or handled in some other means, the operating system would report the error.
Some of the more hardcore versions of Linux (newer flavor of Unix-based operating systems) still report this to the user. However, the C programming language has changed its standard so that a program can return a "void" value, that is to say, return nothing. But to a computer, even nothing is something. And to a computer, every function that it calls has to return something, even if it is that certain something that represents nothing.
Calling my Chronicle this had a few meanings. First, that I was ending on a good note (a non-error state). And second, it was to acknowledge that though I was stopping, I understand what it meant. That is to say, that it didn't necessarily have to be over. It just had to go to a higher order of execution.
runlevel 0
----------
A simpler explanation:
In Unix/Linux environments, the system can come up in certain "runlevels." On Windows, this is similar to starting in Safe Mode versus normal mode. The difference being that you can customize your runlevel to run anything you want. Runlevel 0 is the standard runlevel for shutting down your computer, as well as the command on some Unix/Linux environments to shut things down.
Appropriate, I guess, for an announcement that I was taking a break for a while.
Explicit Deconstructor
----------------------
Creating something in your computer's memory is a pretty uninteresting problem. You have data to read from somewhere, either from user input, network card, tec. What is a more interesting problem is memory deallocation. That is: the deletion and the reallocation of memory that is no longer being used.
Newer programming languages shy away from letting the programmer manage his or her own memory. Most people don't know enough about it to make it efficient or correct. Instead, the program detects when an object in memory is out of scope, or no longer used by any other part of the program. Once this happens, a "garbage collection" side-process comes along a recycles the memory. The programmer is abstracted from the process at only a slight performance hit, depending on the language.
$str = "walks we paths yet walked upon, ";
$str .= "yet why walks they back grinning, ";
$str .= "walked we seems so very long, ";
$str .= "must they seem a beginning."
exit($str);
-----------
Computer-wise, this is pretty uninteresting. All I'm doing is creating a string, concatenating a few more strings to it, and then exiting from the program by displaying this string.
More interesting, I guess, is that this was the beginning to a poem that I had wanted to write for a long time, but had never got around to it, and I suppose, never will. I don't now remember what I had intended it to be about, nor really what I was referring to when I wrote that much down. All I know is that this mini-poem lived at the beginning of my notes file for a few years. Rereading the Chronicle that I embedded this into, I don't really see a good correlation, other than just expressing stuff that hadn't been expressed.
Bad Sectors
-----------
If you have an older computer, or more specifcally, an older hard drive, you might be familiar with this term. A bad sector, in a computing context, is an unreadable or unwritable section of your hard drive. If detected, and if in a relatively unimportant place on your hard drive, a bad sector is not catastropic. Most times if you run a disk checker, these sectors can be identified and avoided in the future. Howeover, the more bad sectors that appear on a disk increases the probability that your data will be corrupted, and more specifically, important data (such as operating system files, etc) will be corrupted, and your system will refuse to boot.
For a Chronicle dealing with memory loss and forgetfullness, I can think of no better title.
break;
------
I chose this for my Chronicle that detailed my life after I took a computing sabbatical, of sorts. At first glance, you might think that I actually chose a normal title, one not steeped in ridiculous computer terminology, but you would be mistaken.
As described earlier, one of the most useful abstract programming tools is the function (takes in parameters, returns a value). However, there are other tools available to programmers. Such things are loops (repeated conditional execution of a series of insructions), if-then-else statements (single-iteration conditional execution), and switch statements (similar to if-then-else, but with different syntax).
At the time that I wrote the Chronicle, I felt like I was living in a loop, and that my computer was partly responsible for my circular nature.
If you've programmed before, you have probably been warned against the "infinite loop." This is where the condition on which your loop is based will always return true, and therefore, will repeat unto infinite.
While most times it just takes a bit of debugging to figure out why you're loop isn't working. But for others, the solution isn't easy or elegant. For this case, most languages provide a "break" command to exit the loop and continue normal execution.
A nausea, Josh or Dahl?
-----------------------
An anagram for "Joshua Alan Rhoades." Of all of these, I would think that somebody would ask about this one. But yeah, no dice.
----
So here's the trend I'm seeing: anything having to do with computers references either a) shutting down something or destroying it, b) stopping processes in some manner, or c) something not working properly. The other stuff was pretty much just noise to fill the space.
I could distance myself from these Chronicles, perhaps by saying that I'm not longer in the same frame of mind, or that when I wrote them that I was at a different point in my life. These would be inaccurate, considering my technologically and personally elitist hidden meanings and intentions are still pretty relevant. I think my intent in embedding such things in my writing is similar to the power-trip many technologically obsessed people like myself get in knowing something that nobody else does. Simply: shoveling misunderstanding on others to mask one's own personal misunderstandings.
This is a pretty poor way to go about things, I think. I'll work on that.
So here goes:
Asynchronous Callback
---------------------
Modern computers, either single processor or multiple processor versions, have the ability to do multiple tasks at the same time. Even more interesting, computers can even behave asychronously (despite being synchronized to a single clock speed), that is, execute a command, but instead of waiting until the command completes, it can go on to do other things, and then once it gets a return from that initial command, go back and finish that thread of execution.
A Callback function is a special function that is executed when a sub-process is finished, usually designed to handle the sub-process return.
An Asynchronous Callback function is similar, except that its calling function does not have to wait for the process to finish, leaving the parent process to do other things.
So that's what it is. But the fun is in the interpretation.
- Previous: return 0;
- Next: Heuristics