Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

291–300 of 320 posts

Re: fork() can fail

#291

Post by wiml »

ajarmst wrote: post #89

Stevens and Rago, "Advanced Programming in the Unix Environment, Volume II", page 211,212. if ((pid = fork()) < 0) err_sys("fork error"); is idiomatic in Unix.

err_sys() is something you have to provide yourself, though, which takes you out of the flow of the code you're thinking about, which is half the reason people don't write error handling in the first place.

Once I discovered the existence of the BSD err()/errx()/warn() functions, though, the error handling in even my quick one-off programs became much better and more informative.

   pid_t child = fork();
   if (child
is idiomatic, quick to write, and produces useful error messages when that "throwaway" program starts failing years later.

Re: fork() can fail

#292

Post by wiml »

quotemstr wrote: post #109
FooBarWidget wrote: post #104

Earlier quoted context omitted.

Unfortunately, posix_spawn is woefully underpowered. I can't make the child process a session leader (setsid) or process group leader (setpgrp). I can't set a working directory. Etcetera.

Yeah --- but at least it's fairly obvious how to add platform-specific extensions that won't conflict with future standards.

And extensions to let us specify failure-case or other behavior of those extensions, and so on. But at that point, we're already heading down the road of implementing a tiny DSL for "the program that posix_spawn() should run after creating the new process but before exec()ing the new executable". Why not simply write that code in the host language? You could specify a thunk of code to be sent to the new process and executed there. Oh, you'll also need to pass any data structures that code relies on--- pass a closure, not just a thunk. And garbage-collected references to any system objects that those data structures rely on. Congratulations, now you have fork()! If you squint a little, that's exactly what fork() provides you --- a closure and continuation.

Re: fork() can fail

#293

Post by throwaway0010 »

derefr wrote: post #283
zurn wrote: post #225

Earlier quoted context omitted.

It's not specifically the lack of cpu timeslices that crowds out other programs, it's more like exhaustion of all the OS resources (process table fills up, file table fills up, memory runs out, swap death etc). Sure if you carefully made everything fork-bomb-resistant then a cpu quota would be a part of it. Container systems use fork bombs as basic test cases.

I'm surprised that this wasn't one of the primary goals of cgroups: the ability to group "all userspace processes" into one cgroup, and then say that that cgroup can in sum only use so much CPU, so many processes, so many inodes, etc. You know, a control plane/data plane separation, without requiring hypervision.

It is. Cgroup provides limits for memory, CPU time. We already have other accounting mechanisms for processes/threads (rlimits) and for inodes and disk space (disk quota systems). We've had those for ages. I imagine there will be more work to integrate these various accounting mechanisms with cgroup as the work continues.

Re: fork() can fail

#294

Post by djcapelis »

__david__ wrote: post #183
djcapelis wrote: post #163

Earlier quoted context omitted.

Not quite. That is according to POSIX, but not the C standard. stderr is defined by the C standard. POSIX is a standard followed by many of the systems that run C. Strictly speaking, stderr does not have to be 2. It wouldn't comply with POSIX in that case, but it would still be C.

You are not correct here: There are no fds in the C standard. The only thing defined is fopen/fread/fwrite (which are FILE*). The open/read/write API is only defined by POSIX, where 2 is most definitely stderr.

I cited the exact portions of K&R that specify stdin, stdout and stderr in my original post: K&R B1, 7.5 & 7.6

Section 7.6 explicitly says all three must be open when the program begins. There are equivalent sections in the formal standards, I cited K&R because it was on my shelf.

Please stop and bother to check your facts before continuing. You're very close to being accurate (POSIX does define open, but C defines stderr and some functions to print to it, the underlying mechanics are the choice of the implementing system.) But don't you think it would be nice to check that I actually am before writing yet another post simply asserting I'm wrong?

Re: fork() can fail

#295

Post by djcapelis »

AnimalMuppet wrote: post #286
djcapelis wrote: post #163

Earlier quoted context omitted.

Not quite. That is according to POSIX, but not the C standard. stderr is defined by the C standard. POSIX is a standard followed by many of the systems that run C. Strictly speaking, stderr does not have to be 2. It wouldn't comply with POSIX in that case, but it would still be C.

Note, however, that these were Unix systems where we encountered the problem, so they should have been POSIX-compliant.

It's quite true! It is worth noting that many systems people call unix are not POSIX compliant, but most try!

Re: fork() can fail

#296

Post by Too »

tedunangst wrote: post #199
azinman2 wrote: post #162

I see a lot of comments blaming the programmer. This is completely the wrong attitude. Why are you treating the programmer like a machine? They're not a machine -- they're human. Regardless if they fully understand the API or not things should have have sane defaults for HUMAN FACTORS reasons. Bugs will always exist. The fact that the Linux kernel has many bugs is just one example of a code base that has over a decad…

Funny you should ask. I used kill -1 about two weeks ago. A for loop would not have worked.

For that purpose there should be a killall() function.

Re: fork() can fail

#298

Post by azinman2 »

nitrogen wrote: post #210
azinman2 wrote: post #162

I see a lot of comments blaming the programmer. This is completely the wrong attitude. Why are you treating the programmer like a machine? They're not a machine -- they're human. Regardless if they fully understand the API or not things should have have sane defaults for HUMAN FACTORS reasons. Bugs will always exist. The fact that the Linux kernel has many bugs is just one example of a code base that has over a decad…

Conclusion: design for humans and default to non-fatal situations. It's a lot safer to fail fast and fail safe than to hobble along with possibly undefined state doing who knows what to the system and to the user's data.

You're missing my point. It's not about undefined state -- it's about sane defaults and APIs that make things that crashes/bad things harder to achieve. Kill's -1 is an example of this -- having a separate killall api is defaulting to a non-fatal situation. Apple's UITableView's is another -- it's so easy for them to rebuild themselves yet instead it crashes on an inconsistency.

Re: fork() can fail

#299

Post by jheriko »

i've never actually used fork... feeling glad now. i probably would have not realised this...

reminds me of allocating memory for an error message to tell someone they are out of memory. :)

Re: fork() can fail

#300

Post by jwr »

Alupis wrote: post #275
jwr wrote: post #247

Earlier quoted context omitted.

You do realize that this, in turn, creates a race condition, right?

? not at all -- you make the deletion of the directory dependent on whether or not you tested true for the directory being present. I don't see why this would cause any race condition...

It does, because somebody might have done something to the filesystem between your test and the rest of your code.

This is why I found your "Defensive Programming 101 really" comment slightly arrogant (perhaps I misunderstood the intention). Writing correct programs is not easy and one should not mock others, because there is always something new to learn.

Post reply on HN