From d9a81669843fae6f3aa2702a7bad59a7523922ee Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sat, 11 Nov 2023 10:40:59 -0800 Subject: [PATCH] Format/typo check 1996/schweikh3 --- 1996/schweikh3/README.md | 57 ++++++++++++++++++----------------- 1996/schweikh3/schweikh3.info | 10 +++--- 2 files changed, 35 insertions(+), 32 deletions(-) diff --git a/1996/schweikh3/README.md b/1996/schweikh3/README.md index eb65353f2..3e39ab8bd 100644 --- a/1996/schweikh3/README.md +++ b/1996/schweikh3/README.md @@ -47,19 +47,19 @@ NOTE: On some systems such as SunOS, one may need to compile with: ### Why I think my entry is obfuscated There are some layout obfuscations that hinder readability, like -some (but not all) one character tokens in column 1. Includes, -defines and declarations of data and functions appear intermixed. -iso646.h is even included in the middle of an expression, how -disgusting. Besides, requiring iso646.h will render the program +some (but not all) one character tokens in column 1. `#include`s, +`#define`s and declarations of data and functions appear intermixed. +`iso646.h` is even included in the middle of an expression, how +disgusting. Besides, requiring `iso646.h` will render the program uncompilable on many systems that have not yet incorporated Amendment One to The Standard. If you, dear reader, suffer from -this disease, just read iso646.h. +this disease, just read `iso646.h`. There are no `if' statements. They have been replaced by -"switch () case 1:" or "switch () case 0:" etc. At least one -switch has a declaration after the opening brace, booh! -Identifiers are named after random programming languages, Basic, -Cobol, F77, awk etc. +`switch () case 1:` or `switch () case 0:` etc. At least one +`switch` has a declaration after the opening brace, booh! +Identifiers are named after random programming languages, BASIC (as `Basic`), +COBOL, F77, awk etc. You have to select maximum ANSI C conformance of your compiler. The source fails to compile under a C++ compiler due to @@ -94,15 +94,15 @@ The source fails to compile on obsolete systems with obsolete memory models due to the identifier `far` (to be honest: this is untested :-) ). -Does your indent cope with backslash/newline pairs inbetween -keywords like in "re\turn"? Solaris' indent inserts spaces\ -and thereby renders the source uncompilable... +Does your indent cope with backslash/newline pairs in between keywords like in +`re\turn` where the `re\` is at the end of a line? ? Solaris' indent inserts +spaces and thereby renders the source uncompilable... The indented source will exhibit different semantics when indenting changes the number of lines (due to using the `__LINE__` macro in an expression). -And what about sizeof `__TIME__`? This one's for the philosophers\ +And what about `sizeof __TIME__`? This one's for the philosophers and physicists among us programmers. What is it? `sizeof (char *)`? -- no. `strlen ("hh:mm:ss")`? -- no. It's the same as `sizeof __DATE__ - sizeof "no"` :-) @@ -114,22 +114,22 @@ possible execution paths. ### What this program does This program tests your operating system's allocation honesty. It -forks a child that will allocate as much as possible with byte +forks a child that will allocate as much memory as possible with byte granularity and then write to every 1024th byte, at the same time -writing a status report on stdout. This way each page of the +writing a status report on `stdout`. This way each page of the allocated virtual memory will eventually be referenced. Without -any arguments, malloc() will be used to allocate memory. If the -first arg starts with c, calloc() will be used instead. +any arguments, `malloc(3)` will be used to allocate memory. If the +first arg starts with `c`, `calloc(3)` will be used instead. I distinguish three different behaviours: -1. OS without memory overcommit: malloc does not lie -- you can use all memory +1. OS without memory overcommit: `malloc(3)` does not lie -- you can use all memory the OS granted to you. -2. OS with memory overcommit: malloc lies -- any program may get killed at +2. OS with memory overcommit: `malloc(3)` lies -- any program may get killed at random when the OS can not acquire a free page. -3. OS with pseudo memory overcommit: malloc lies -- The OS puts processes to +3. OS with pseudo memory overcommit: `malloc(3)` lies -- The OS puts processes to sleep for which it can not acquire a free page. Because other processes are also affected this way, the system slows down and quickly becomes totally unusable (also known as "thrashing"). Because more and more processes wait for memory @@ -137,31 +137,34 @@ returned by other exiting processes the system eventually enters a deadlock situation and effectively halts. I had the pleasure and pain to find all three behaviours on the -platforms I use regularly. What follows are the outputs for +platforms I use regularly. + +The file [schweikh3.info](schweikh3.info) has output for Solaris, FreeBSD and Linux. The Linux case is interesting in that -the behaviour changes when calloc is used instead of malloc. +the behaviour changes when `calloc(3)` is used instead of `malloc(3)`. For FreeBSD, the last two lines are not messages stemming from my program but issued by the syslog daemon. + ### Implementation remarks How can we distinguish the three different OS types from the table above? -Obviously, type 1), no overcommit, is easy. +Obviously, type (1), no overcommit, is easy. -For type 2), random kill, we need to fork a child that can be killed +For type (2), random kill, we need to fork a child that can be killed and whose exit status the parent collects and decodes. Here's where POSIX enters the scene. -Type 3), thrashing, was the hardest part. The first attempt was to +Type (3), thrashing, was the hardest part. The first attempt was to measure the elapsed processor time it takes to write a single byte (using `clock()`). If a certain threshold is reached I assume the system is thrashing. When thrashing, however, the process does not consume processor time in a noticeable amount any longer and I lose. -So I switched to measuring wall clock time using `time()`. On the one +So I switched to measuring wall clock time using `time(3)`. On the one system that I observe thrashing (Linux) this works (although the -value returned by time seems to 'hang' sometimes when the OS thrashes. +value returned by `time(3)` seems to 'hang' sometimes when the OS thrashes. Exceeding a threshold of 5 seconds may be detected only after half a minute or so. diff --git a/1996/schweikh3/schweikh3.info b/1996/schweikh3/schweikh3.info index 7e9255e96..358577cd9 100644 --- a/1996/schweikh3/schweikh3.info +++ b/1996/schweikh3/schweikh3.info @@ -1,6 +1,6 @@ ***** SOLARIS 2.5 (sparc): - % prog + % schweikh3 Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope @@ -41,7 +41,7 @@ ***** FreeBSD 2.1 (i386): - % prog + % schweikh3 Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope @@ -82,7 +82,7 @@ Nov 24 18:11:56 /kernel: swap_pager: out of space Nov 24 18:11:57 /kernel: Process 5 killed by vm_fault -- out of swap - % prog c + % schweikh3 c Trying to calloc 2048M+0K+0 bytes..nope Trying to calloc 1024M+0K+0 bytes..nope Trying to calloc 512M+0K+0 bytes..nope @@ -96,7 +96,7 @@ ***** Linux 1.2.13 (i386): - % prog + % schweikh3 Trying to malloc 2048M+0K+0 bytes..nope Trying to malloc 1024M+0K+0 bytes..nope Trying to malloc 512M+0K+0 bytes..nope @@ -132,7 +132,7 @@ Able to malloc 23M+1023K+1023 bytes 23294 kilo bytes ok malloc lied! Thrashing - % prog c + % schweikh3 c Trying to calloc 2048M+0K+0 bytes..nope Trying to calloc 1024M+0K+0 bytes..nope Trying to calloc 512M+0K+0 bytes..nope