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

Computer Science from the Bottom Up

bottomupcs.com

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Computer Science from the Bottom Up

#31

Post by Joker_vD »

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the name of the application/executable file, and it launches. Instead, there is a small dance of duplicating itself and then re-writing one of the copies--try not to get tangled up in the legs while doing that!

The fork+exec has many unobvious advantages over CreateProcess, but also disadvantages, and one of them is that it's, in my opinion, a completely unexpected approach: I can't think of any other system object that can only be created by first copying another already existing object and then overwriting the newly created one if needed. Files of any kind (folder/pipe/socket/etc)? Memory mappings? Signal handling? Process groups/sessions? Users/groups? The processes seem to be unique in this regard. How did people come up with this approach? That would be an interesting discussion, I think.

Instead, it's just described as the completely self-justified, with description of "zombies" thrown in the end for boots: and the zombie processes are pretty much an accidental artifact of early UNIX design; if the fork was returning not only globally visible (and therefore unstable) PID but also an fd associated with the child process, neither wait/waitpid syscalls nor reaping duties of PID 1 would have been necessary.

Re: Computer Science from the Bottom Up

#33

Post by kccqzy »

Joker_vD wrote: post #31

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…

Well we do have a library call for launching a new process called posix_spawn(3), but it's complicated mainly because they are a lot of options you want to configure when launching a process: which file descriptors would you like to close, which would you like to share with the newly created process, what uid the new process should have, what working directory it should have, etc. It's just a large and complicated call.

But with fork/exec, all of that setup becomes just normal code you run after fork but before exec. You want the child not to have a certain file descriptor? Just close it after fork. You want to drop privileges when running the child? Same thing, just setuid/setgid/setgroups after fork. You want to set up resource limits for the child? Again just setrlimit after fork.

It avoids a lot of complexity in the system call itself. (Naturally, it adds some other complexity elsewhere.)

Re: Computer Science from the Bottom Up

#34

Post by brundolf »

_vr9d wrote: post #26
brundolf wrote: post #2

This seems highly focused on systems; I wouldn't call it representative of "Computer Science" as a whole. Only maybe 2-3 of the classes in my computer science degree were focused on this kind of stuff. Still seems like a good resource, just perhaps mislabeled.

The reason for the name seems to be because of its focus on systems. I do agree that the way it's labeled isn't the best, but it's not trying to be representative of all Computer Scionce. In fact, it seems to specifically be trying to have a different focus than a cs degree: > This book aims to move in completely the opposite direction, working from operating systems fundamentals through to how those applications are…

"opposite direction" tends to imply "the same content, just with a different order/framing". Whereas the OP leaves out the majority (not all, but more than half) of what people tend to put under the term "computer science" completely

Re: Computer Science from the Bottom Up

#35

Post by Joker_vD »

kccqzy wrote: post #33
Joker_vD wrote: post #31

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…

Well we do have a library call for launching a new process called posix_spawn(3), but it's complicated mainly because they are a lot of options you want to configure when launching a process: which file descriptors would you like to close, which would you like to share with the newly created process, what uid the new process should have, what working directory it should have, etc. It's just a large and complicated ca…

Yes, I know. But you only figure it out after you've done you fair share of IPC and management of worker processes by hand. When you're a fresh student, this "fork+exec" just seems like a pretty ridiculous way to organize things: why not just launch the executable you want to launch immediately? Nope, that's at best postponed until the chapter on IPC, at worst it's never discussed at all, so you're left puzzled and with "okay, I guess that's how things are done, if you say so..." feeling.

Oh, and by the way: we have open()/fcntl() for opening files and then fiddling with their settings instead of one open() call with 20 arguments; we could easily have had launch() with the same parameters as execve() that would launch the new process suspended, then we could use... I dunno, even fcntl() on the process's descriptor to configure all those things and then send it SIGCONT when we're done setting it up.

Re: Computer Science from the Bottom Up

#36

Post by jll29 »

ravi-delia wrote: post #12
neatze wrote: post #10

Earlier quoted context omitted.

hmm, applied science is not engineering ?

Applied science is engineering, by and large, but it's worthwhile to have different words for different things. 'Engineering' is one, 'Science' is another, even though the latter is useful to the former. Of course, Computer Science is almost no science, most degrees are some blend of math and engineering.

As with anything that entirely depends who is at work. Watching Linus Torvalds is going to make you arrive at your answer, but if you followed Don Knuth, you may have to reconsider.

Re: Computer Science from the Bottom Up

#38

Post by kccqzy »

Joker_vD wrote: post #35
kccqzy wrote: post #33

Earlier quoted context omitted.

Well we do have a library call for launching a new process called posix_spawn(3), but it's complicated mainly because they are a lot of options you want to configure when launching a process: which file descriptors would you like to close, which would you like to share with the newly created process, what uid the new process should have, what working directory it should have, etc. It's just a large and complicated ca…

Yes, I know. But you only figure it out after you've done you fair share of IPC and management of worker processes by hand. When you're a fresh student, this "fork+exec" just seems like a pretty ridiculous way to organize things: why not just launch the executable you want to launch immediately? Nope, that's at best postponed until the chapter on IPC, at worst it's never discussed at all, so you're left puzzled and w…

When you are a fresh student, and when fork/exec is too advanced for you, just use system(3). Not recommended for production use, but that's indeed the easiest way to launch an executable.

Do we optimize our system call design for fresh students or for professionals?

Re: Computer Science from the Bottom Up

#39

Post by mariodiana »

I can't be the only one, but I feel pretty sure I'm in a minority among computer programmers. This "bottom-up" approach is just not the way my brain works. I definitely feel I'm a top-down sort of thinker and learner, and this puts me at a disadvantage, regarding the literature and approach in this profession.

Are the terms describing the two approaches here "empirical" versus "rational"? I'm talking about building bit by bit as opposed to getting an overview and then drilling down. I definitely feel like I benefit from the second. And I almost feel like it may not be too strong to suggest that I'm actively harmed by the first.

Something like the author's approach is great, for my purposes, when I already pretty much understand something. But I can't start here.

Again, I feel like I'm in a minority. But anyone else have this turn of mind, too? How do you cope? Do you just look for other materials?

Re: Computer Science from the Bottom Up

#40

Post by dataflow »

Joker_vD wrote: post #31

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…

What I hate about fork is that it fundamentally doesn't even make sense. You fork a process with a window, what happens to that window? Does it get duplicated? Do both control the same window? It has no sensible behavior in the general case without cloning the whole machine, and even then, your network isn't going to get forked. There are limited cases where it could make sense, but the fact that that's not true in general should make it fairly obvious that we need a different spawning primitive. It boggles my mind that people teach fork as if it could be the primitive.
Post reply on HN