Check out my first novel, midnight's simulacra!
Procfs: Difference between revisions
From dankwiki
| Line 46: | Line 46: | ||
</pre> | </pre> | ||
We start at the lparen following whitespace following digits. But where do we end? | We start at the lparen following whitespace following digits. But where do we end? <i>There is no valid delimiter</i>. Even if we don't care about the name of the process, and just want to know its state ('S'leeping in all three cases above), we can't identify where the next token begins. Any potential delimiter can be encoded into a filename under this scheme. Together with the varying fields over the years, one must lex backwards from the right, since the common (and most important) fields are in the front. | ||
What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the | What, you ask? Couldn't we read <tt>proc/PID/comm</tt> and thus know the exact match to expect? Unfortunately, a process (or even thread) can change its "comm value". According to the <tt>proc(5)</tt> man page, <tt>stat</tt>'s second field reproduces the name of the <i>executable</i>, and thus a process which had changed its comm value would not facilitate sane lexing. The documentation is incorrect: | ||
<pre> | <pre> | ||
