fork() can fail

Post by ionelm » Wed, Aug 20, 2014, 8:31 PM UTC

    >>> resource.setrlimit(resource.RLIMIT_NPROC, (0, 0))
    >>> os.fork()
    Traceback (most recent call last):
      File "", line 1, in 
        os.fork()
    OSError: [Errno 11] Resource temporarily unavailable

Post by mindajar » Wed, Aug 20, 2014, 8:34 PM UTC

colanderman wrote: post #33

cperciva wrote: post #16

Earlier quoted context omitted.

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

For daemonization, daemon(3) is better (EDIT: assuming you only care about Linux). (It also chdirs to /, closes STD*, and detaches from the terminal.)

Post by eshyong » Wed, Aug 20, 2014, 8:34 PM UTC

leni536 wrote: post #30

spudlyo wrote: post #20

If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest "it cannot happen to me", the gods shall surely punish thee for thy arrogance. [0] [0]: http://www.lysator.liu.se/c/ten-commandments.html

Note that wasn't the real reason. At the bottom you can see an edit which reads: "I was wrong about why malloc finally failed! @GodmarBack observes, in the comments, that x64 systems only have an address space of 48 bits, which comes out to about 131000 GB. So, on my machine at least, the malloc finally failed because of address space exhaustion."

Post by quotemstr » Wed, Aug 20, 2014, 8:38 PM UTC

cperciva wrote: post #46

quotemstr wrote: post #35

I wish posix_spawn were ubiquitous; it's a much better process-launching interface than fork: it's naturally race-free and amenable to use in multi-threaded programs, and unlike fork(2), it plays well with turning VM overcommit off. (If overcommit is off and a large process forks, the system must assume that every COW page could be made process-private and reserve that much memory. Ouch.)

Even if VM overcommit is enabled, you shouldn't be forking from large processes, because the necessary kernel VM manipulation will kill your performance.

Post by arthurcolle » Wed, Aug 20, 2014, 8:39 PM UTC

runarb wrote: post #8

Easy to test out to. In C: #include int main(void) { while(1) { fork(); } }