In Japan is the future behind or in front?

Mae (前) in Japanese means in front but also means ago, thus is used to refer events in the past as well to point something that is front….

At the beginning this didn’t make sense to me, despite the fact that I am Western person: the past is behind, it already passed; the future is in front, it is coming. Japanese people seems to be confused with this fact, they agree that future is in the front because it is coming but they also say that the past is in the front “in front,前 “…that is not congruent right?. How is possible that both the past and the future be in the front….seems like many Japanese people have not thought about this until the question arises.

Well if thinking of 前 as Latin “prae” everything makes sense (except for the point that, both present and future being in front), prae means before, but also means in front.

Prae and  both refer to spatial dimension: in front, and temporal dimension: before.


Why fork(2) doesn’t copy all threads?

There are many advises discouraging the use of fork in threaded applications…it is even on “Programming with POSIX Threads” by Butenhof….Avoid using fork in threaded program (if you can) unless you intend to exec a new program immediately.

Certainly using fork in threaded programs is not a good idea but sometimes it becomes necessary, so, the point is: why fork(2) doesn’t copy all threads?

First time I  asked myself  “does a forked process have all the parent’s threads?” I thought yes but, I was wrong.  The specification say it: A process shall be created with a single thread

So why?

  • Because is more practical, easier, and less complex.
    • There are only two alternatives, copy all of them or copy just the one calling fork. Each alternative has it own set of complexities, so, which approach is easier to follow? Copying only the thread that called fork.
  • Critical sections: Other threads could be executing critical sections at fork() call, therefore child process might get a copy of objects that are in undefined status => causing undefined behavior on the application. Σ =
  • Parent and child could be reading from fd or socket at the same time, or even worse writing to it.  あぶない
  • Since state in parent and child should be the same, all parent’s threads should be stopped before to be forked and if in the middle of a system call EINTR would be raised
  • .

Specification mentions forkall was rejected, that means that I was not alone.
It is easier to deal with one thread using pthread_atfork() than dealing with multiple threads on the child.
As long as it is specified it is OK