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

151–160 of 320 posts

Re: fork() can fail

#151

Post by dllthomas »

wmil wrote: post #150

The kill -1 behaviour seems like a bug. Sure, it's documented, but how often is it done on purpose? It seems like something that should at least be a separate function.

If I set off something that proves to be a fork bomb as an unprivileged user, kill -1 might be a reasonable approach. And note that kill exists as a builtin in bash, so you can run it without forking a process.

Hopefully doesn't happen often, but potentially very useful in narrow circumstances. The problem is it being -1, not it being available. If it took an argument to kill that you'd never accidentally generate as a PID then it might as well be a different function. Of course, with negative numbers otherwise referring to process groups, there's not a lot of room remaining, so yeah...

Re: fork() can fail

#152

Post by maxlybbert »

_yosefk wrote: post #130
takeda wrote: post #101

Earlier quoted context omitted.

Similarly python throws an exception, and I bet other languages have their own behaviors, but in case of C this is the only way (or at least it is the only non complicated way to do it). When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.

Nothing in C forces the API designer to use -1 as "bad PID" in one place and as "the set of all PIDs" in another, however. Perl's undef isn't that different from returning, gosh, -2 or any other bloody number except -1 in C.

> Perl's undef isn't that different from returning, gosh, -2 or any other bloody number except -1 in C.

Returning undef has the advantage of being something completely useless as a process ID for any other function call.

Re: fork() can fail

#153

Post by hamburglar »

AnimalMuppet wrote: post #78
cperciva wrote: post #42

Earlier quoted context omitted.

You mean, after exit(0) returns?

Not after exit(0) returns, no. Instead, you're going to want it after some programmer removes exit(0) six months from now.

smart-ass comment: you should put two breaks in for when some programmer removes one of them six months from now. ;)

edit: i know it's not totally analogous since removing the exit and not noticing there's no break is a lot more likely than just randomly removing a break, but the "let's prevent someone clumsy from screwing this code up in the future" argument always makes me laugh a little.

Re: fork() can fail

#154

Post by alxnlssn »

knocte wrote: post #139
andrewchambers wrote: post #119

Earlier quoted context omitted.

Multiple return would be fine too. pid,err = fork()

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of syntax that matches the one from Go. So then I'm guessing that Go would simply ignore the error in this case. However, having a proper exception mechanism, if you don't catch the problem, then it bubbles up, and the program doesn't continue with wrong data (whi…

The compile will fail if err is unused. You have to explicitly ignore it by doing like this:

pid,_ = fork()

Re: fork() can fail

#155

Post by sbmassey »

JD557 wrote: post #144

Is there any clean way to use an Option/Maybe monad in C (or C++)? It should be a simple way to solve problems where error codes are valid inputs of other functions. The simplest way I can think of is: struct maybe { bool isEmpty; void* value; } Although I wonder if using C++ templates, classes and operator overloading is possible to make a more practical implementation (using void* does seem like a bad idea).

In C++ std::optional does the trick, as of version 11, and boost::optional previously.

In C ... hrm you could probably wrangle some macros around that struct if you were desperate.

Re: fork() can fail

#156

Post by Hello71 »

quotemstr wrote: post #90
cpeterso wrote: post #82

Earlier quoted context omitted.

> cannot possibly fail in a well-formed program I think that's your answer. A mutex error return probably indicates an application bug, such as double unlock. You should probably assert or abort on "can't happen" mutex errors. Programmers are lazy. If they take the time to document an error return value, then you should probably heed their warnings. :)

Indeed. I like using a VERIFY macro: #ifdef NDEBUG # define VERIFY(x) ((x), 1) #else # define VERIFY(x) assert((x)) #endif Then you can write VERIFY(pthread_mutex_unlock(&lock) == 0); You don't need, however, to consider the possibility of your program continuing to run after pthread_mutex_unlock fails.

man 3 assert

Re: fork() can fail

#157

Post by gilgoomesh »

FooBarWidget wrote: post #104
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.)

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.

The role of posix_spawn is for spawning "helper processes", not starting new process groups. This should overwhelming be your common launch case. posix_spawn is so much faster (on BSD/Mac anyway) that fork should be outright avoided.

Processes requiring other permissions can/should be spawned by asking systemd/chron/init/launchd to launch them for you.

Re: fork() can fail

#158

Post by nikita »

Yes, fork can fail and we ran into this a few years ago at MemSQL. The problem was that MemSQL would allocate a lot of memory and linux wouldn't allow to fork such a process. A remedy to that is to create a separate process and talk to it via tcp. This small and low on memory consumption process is responsible for fork/exec paradigm.

Re: fork() can fail

#159

Post by donatj »

And this is why I think Go-lang and its multi-return is the way of the future. In Go you are required to handle errors. If you want them to go away you have to explicitly use an _ and thats really easy to find in the code and shame the person who did it. Nothing fails silently. Nothing fails via primary return. It is such greatness it is hard to express.

Re: fork() can fail

#160

Post by marcosdumay »

brazzy wrote: post #112
marcosdumay wrote: post #99

Earlier quoted context omitted.

Except that exceptions and non-garbage collected languages don't work that well toguether.

I'll have to admit I'm not very familiar with such languages, but shouldn't finally clauses and RAII be sufficient to deal with any necessary cleanup?

Exceptions disrupt the program flow at any place, including constructors and destructors.

It's not easy to guarantee that you deallocate on destructors exactly the resources that were allocated at the constructor when both of them can stop their execution at any time. Finally clauses are technically enough, but each allocation needs the same level of attention non-memory resources (e.g. connections, files) get on other languages.

Post reply on HN