Are processes :: detach and Process :: wait mutually exclusive (Ruby)?

I will reorganize a bit of parallel processing on my Ruby on Rails server (runs on Linux) to use Spawn. Spawn::fork_it documentation claims that after disconnecting you can still expect forked processes: https://github.com/tra/spawn/blob/master/lib/spawn.rb (line 186):

 # detach from child process (parent may still wait for detached process if they wish) Process.detach(child) 

However, the Ruby Process::detach documentation says you shouldn't do this: http://www.ruby-doc.org/core/classes/Process.html

Some operating systems maintain the status of completed child processes until the parent receives this status (usually using some option wait (). If the parent never collects this status, the child remains around as a zombie process. Process :: detach prevents this by setting up a separate a Ruby thread whose only job is to obtain the status of the pid process when it ends, use detachment only when you do not intend to explicitly wait for the child to finish working.

However, Spawn::wait effectively does this by wrapping Process::wait . On the other hand, I specifically want to use the Process::waitpid2 to wait for child processes instead of using the Spawn::wait method.

Will debugging and waiting work incorrectly on Linux? I am concerned that this could lead to a race condition between the disconnected thread reaped and the pending parent process, as for whoever first collects the child status.

+4
source share
1 answer

The answer to this question is in the documentation. Do you write code for your own use in a controlled environment? Or widely used by third parties? Ruby is written for widespread use by third parties, so their recommendation is not to do something that might fail on "some operating systems." Perhaps the Spawn library is designed primarily for use on Linux machines and tested only on a small subset of it, where this tactic works.

If you distribute the code you write to be used by anyone and everyone, I would take the Ruby approach.

If you control the environment in which this code will be executed, I would write two tests:

  • A test that spawns a process separates it and then waits for it.
  • A test that starts a process and then just waits for it.

Count the failure rate for both, and if they are equal (within the acceptable range), go for it!

0
source

All Articles