Computer Science from the Bottom Up

Post by megous » Thu, Apr 29, 2021, 7:36 PM UTC

wrnr wrote: post #17

The ELF binary format, really? This is like a course advertising itself as an introduction to normative ethics and proceeding to lecture people on canon law in the 14th century in Flanders. Like sure if you into obscure shit this might be interesting but dunno what one has to do with the other.

Post by megous » Thu, Apr 29, 2021, 7:38 PM UTC

dataflow wrote: post #48

megous wrote: post #46

Earlier quoted context omitted.

Depends on what do you mean by window. If the window lives in a X server and you clone the client, window will obviously not get duplicated. It's quite clearly defined what gets duplicated and what gets shared on clone()/fork(). There really is no ambiguity.

I'm not saying a particular implementation is ambiguous as to what it does . Obviously any implementation will do something . I'm saying that fork as a concept is ambiguous as to what it should do.

Post by megous » Thu, Apr 29, 2021, 7:41 PM UTC

Joker_vD wrote: post #47

megous wrote: post #46

Earlier quoted context omitted.

Depends on what do you mean by window. If the window lives in a X server and you clone the client, window will obviously not get duplicated. It's quite clearly defined what gets duplicated and what gets shared on clone()/fork(). There really is no ambiguity.

So, do threads get duplicated or shared? Or something altogether different happens to them?

Post by Joker_vD » Thu, Apr 29, 2021, 7:46 PM UTC

kps wrote: post #49

Joker_vD wrote: post #41

Earlier quoted context omitted.

We 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".

If 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.)

Post by khaledh » Thu, Apr 29, 2021, 8:43 PM UTC

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…

    ... the separation of fork() and exec() is essential in building a UNIX shell,
    because it lets the shell run code after the call to fork() but before the call
    to exec(); this code can alter the environment of the about-to-be-run program,
    and thus enables a variety of interesting features to be readily built.

    ...

    The separation of fork() and exec() allows the shell to do a whole bunch of
    useful things rather easily. For example:

      prompt> wc p3.c > newfile.txt
    
    In the example above, the output of the program wc is redirected into the output
    file newfile.txt (the greater-than sign is how said redirection is indicated).
    The way the shell accomplishes this task is quite simple: when the child is
    created, before calling exec(), the shell closes standard output and opens the
    file newfile.txt. By doing so, any output from the soon-to-be-running program wc
    are sent to the file instead of the screen.