Hacker News Reader

Comment by dsp1234 | Hacker News Reader

If I have code that is:

  executeStep1();
  //Step 2 requires step 3 to be run first
  executeStep2();
  executeStep3();

I don't expect my compiler to go ahead and run step 3 first. Systemd is choosing code comments over code organization. The tests are green, until we run them under a compiler than prefers comments over procedural organization.

View on HN

I don't mean to advocate for systemd's approach, but they are not the first compiler to give meaning to information in comments.

For example, there exists a Javascript compiler that puts static type annotations in the comments: https://github.com/google/closure-compiler/wiki/Annotating-J...

For static analysis and linting in C information gets held in comments as well.

Unfortunatley, about the only thing everyone can agree on is:

  /* fallthrough */

For when you intentionally don't put a break in a case statement.

> I don't expect my compiler to go ahead and run step 3 first.

You would be surprised[0]. In low level code (in some cases) you'll need memory barriers[1] to ensure the proper order of instructions execution.

Even in higher level code your compiler's optimization algorithm may decide that it's faster to execute step 3 first if it thinks the result would be the same.

[0] https://en.wikipedia.org/wiki/Out-of-order_execution

[1] http://irl.cs.ucla.edu/~yingdi/web/paperreading/whymb.2010.0...

Out-of-order execution always has the same answer that would occur from a single threaded perspective. There's no "thinks the result would be the same" about it - the result is the same.

You get into trouble when you:

1) assuming ordering to external peripherals (e.g., memory mapped I/O)

2) assuming stores/loads are happening in a specific order (e.g., other threads either pre-empt or are simultaneously running) causing data races

Your response makes it sound like a compiler could reorder functions like:

  x=5;
  x=add(x,5);
  x=multiply(x,10);
  printf("%d", x);

and you could expect to get either 100 or 55 as an answer if you didn't use fences. That's not true. The answer will always be right (100) no matter what OOO, speculative execution, etc happen.

If you read my post carefully the "thinks the result would be the same" was about compiler optimization case, not processors' out-of-order execution.

Take this example:

    a = 5;
    b = sqrt(44);
    return a * b;

If the optimizer is sure (and strict aliasing[0] also helps to be sure in many other not so obvious cases) that the sqrt function is not using the a variable then it can swap lines 1 and 2 in the generated machine code, and the result will be the same.

In your example changing lines 2 and 3 will alter the result naturally so the optimizer won't touch it.

[0] http://dbp-consulting.com/tutorials/StrictAliasing.html

I thought the headers were interpreted by sysvinit as well, as they were intentionally part of the design. Am I mistaken?

System 5 rc (rc, not init, note) didn't have such a concept. Even the original van Smoorenburg clone of rc didn't have this.

The LSB headers came along some years later. They are one of two different header styles that systemd's conversion tool understands, in addition to supporting the case where there are no headers at all. There are multiple extensions to van Smoorenburg rc. The LSB headers are just one such extension, understood by toolsets on some operating systems and not others.

* http://unix.stackexchange.com/a/233581/5132

Because init scripts are being used in such a strange and non-rigorous way (configuration and operation combined in single files, with execution order implied by the name of each file), I don't think it's fair to draw such a direct parallel to the more formal languages used today for programming.

The fact that they are syntactically formatted as comments is irrelevant. There is a spec, and that spec is respected by many tools besides systemd, including insserv (which was used for parallel boot on Debian for quite a while before systemd became default).

Because shell scripts are such a terrible format for init scripts, they were standardized as comments to the shell. But they are not comments simply for human use.

An analogy is the type-checking syntax in Python 2, which couldn't pick up a syntax change like Python 3 does. They're formatted like comments. They're not arbitrary strings for amusement, and a type checker is entirely right to complain if the appropriately-formatted comments are invalid. If you want to express things for humans, you're welcome to use normal unstructured comments.

Reply on news.ycombinator.com