4 ms·
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 "f
by Joker_vD 6y ago
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.
- kccqzy 6y agoWhen 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?
- Joker_vD 6y agoWe were talking about the presentation of "fundamentals" in the courses on Computer Science, right? The fork/exec design is highly non-trivial and so should probably deserve more discussion, with examples of alternative designs and design considerations, than mere "that's how new processes are created, nothing special here, let's move on".
- kps 6y agoIf you want to look at it as ‘fundamentals’, fork only requires the concept of a task, whereas your top-level comment's suggestion also requires (a) secondary storage, (b) organized into files, (c) that can be named. (That's not why Unix developed with fork, though.)
- Joker_vD 6y agoThe (b) and (c) are not really needed: early timesharing systems managed to launch processes straight from the punched card decks IIRC. And without (a), what do you even need the second, identical task for? I guess it could be used parallelize crunching the numbers, but that's it; and probably that should perhaps be done from the system operator layer anyway? Like, "launch 5 copies of program on this deck but mark one specific slot in memory different for them, so they would know their ID".