This list is of no particular orderning, neither of importance nor chronological. It is written in the order in which I remembered them as I was writing this.
fork-bomb
Can’t have a discussion about forks without discussing fork bombs, and here they are, in various languages.
Cheap shot, I know, but I’ve always thought they were fun and interesting.
I would’ve included a RosettaCode submission instead but I couldn’t find an entry for it, so this is the next best thing.
What’s so special about message passing in Smalltalk?
This is a bit of a detour from the main topic which is concurrency, but I felt like bringing it up because I was so enthralled with the idea ever since I found it.
Smalltalk essentially came up with the idea of encapsulating processes as objects that communicate by default through message-passing.
The idea was already floating around at the time, but Smalltalk took it to the extreme, to the point where the actual concept happens by default outside of concurrency, and where most Smalltalk images would execute one object at the time.
The idea is also incredibly Unix-like, with Alan Kay having gone on record to have imagined it to replace data and data structures entirely, having processes communicate in a common message-passing protocol from the bottom all the way up, even between computers and networks.
Fork vs Clone on 2.6 Kernel Linux
This link clears up some misconceptions about fork() and clone().
It turns out that in the actual implementation level, the former just calls the latter as a specific instance for forking processes, whereas the latter can be used for several different actions related to process duplication which may or may not be processses nor threads.
clone(2)
This documentation page explains more in-depth the differences between the two functions mentioned prior.
It explains the level of flexibility given with calling clone() with regards to virtual addresss spaces, file descriptors, and signal handler tables.
Pipe Syscall
I was having a bit of trouble understanding the way the pipe() function works and this sort of helped clear up some of my problems.
One thing of note is the fact that one can simply access both endpoints of the pipe from the same program despite this providing basically no communication with any external process.
Daemons vs orphans
I’ve always found it sort of interesting the way daemons: the fact that they’re intentionally orphaned.
This link serves moreso as background on to this fact.
The idea that it’s more useful for a process simply to be inaccessible by the user seems a tad bit counterintuitive to me, precisely because I’m used to the model of computing where everything is actually handled on accounted for.
Shichao’s Notes - Daemons
This link sketches out a more hands-on approach to daemons, and even goes a bit into the process of daemonizing processes.
It has some interesting bits: for example, one issue I didn’t think about was the fact that daemons can’t actually write to any standard error log because it’s not supposed to be associated to any standard I/O.
Thusly they use a centralized daemon logging facility, such as the BSD syslog.
Thread Pools
I was always sort of aware of thread pools while I was working with Java, having run into many a Mockito error where it throws it to some threading problem when in reality it was something completely unrelated.
I do find it interesting though that the idea of fixing the number of possible threads for a process somehow gives it some speedup just by automatically replacing it whenever possible.
Rules of thumb when forking
This link gives a general summation on the advice and rules of thumb one should follow most of the time when dealing with fork() and multithreading processes.
It should be noted though that the idea that a single threaded child is worse than a multithreaded one, but maybe I’m just mistaking the actual message here.
Deadlock
This is a bit of a headstart on next week, but here we are.
Deadlocks are race conditions on fork()ed processes, formally speaking, in which both processes are “locked” and terminated indefinitely.
This was hinted in the slides on race conditions and I thought it was interesting.
That’s it for now. またね！