How does fork work with open files?

Patreon ➤ / jacobsorber
Courses ➤ jacobsorber.th...
Website ➤ www.jacobsorbe...
---
How does fork work with open files? // Fork clones processes. We've talked about that before, and we know that fork copies a process's memory, but what happens with open file handles? In this video, I'll provide a little insight.
Related Videos:
Fork: • Creating new processes...
More Fork: • Making forked clones m...
***
Welcome! I post videos that help you learn to program and become a more confident software developer. I cover beginner-to-advanced systems topics ranging from network programming, threads, processes, operating systems, embedded systems and others. My goal is to help you get under-the-hood and better understand how computers work and how you can use them to become stronger students and more capable professional developers.
About me: I'm a computer scientist, electrical engineer, researcher, and teacher. I specialize in embedded systems, mobile computing, sensor networks, and the Internet of Things. I teach systems and networking courses at Clemson University, where I also lead the PERSIST research lab.
More about me and what I do:
www.jacobsorbe...
people.cs.clem...
persist.cs.clem...
To Support the Channel:
like, subscribe, spread the word
contribute via Patreon --- [ / jacobsorber ]
Source code is also available to Patreon supporters. --- [jsorber-youtub...]

[@godnyx117]

Once again, you prove why you are one of the best out there! I did know that they would get their own copies and opening and closing files would not affect each other, but I would probably forget about the Write buffer. As for reading and the file "seek" been shared, the man pages do not mention that, so I didn't know that, and you probably saved me from hours of debugging!

[@esrx7a]

Great content bro, C is the most powerful feeling in the world

[@nunyobiznez875]

Great video. I really like these videos that ask interesting implementation questions, like this.

[@davidx5828]

I really look forward to the videos when they come out. Thanks!

[@austinraney]

Fun video! I wish you would have explained why this behavior is expected (e.g. process level fd table vs file table). I think you’ve already covered these topics before, but it would have been nice to tie together what is going on at the kernel level in another practical example. As always, keep it up! You are one of my favorite creators to watch!

[@unperrier]

Hi Jacob, what's up buddy? Been a month without any video... is everything fine? Hopefully just busy.

[@MohdYusufAbdulHamid]

Great videos, I love your channel diving deep in the low level details. One theme I noticed, perhaps using “autosave” feature on vscode would improve your presentation and interruptions in your flow. I honestly didnt like that feature at the start, but have grown to like it.

[@peczenyj]

Some people may not realize that if you are using sockets and you fork to be possible do something in parallel, if you don’t open the socket in the child you will may find a bottleneck - imagine a database connection for instance. I had this issue in Perl, sometimes I ended storing the original pid with the socket and if change I need to reopen it. If you ever worked with a language with GIL you know that fork is your friend but you can’t just abstract the operational system

[@greg4367]

Educational, as always.

[@sanderbos4243]

Really cool to see file descriptor != file description on this channel!

[@rogo7330]

For the last example. I use "descriptor has a cursor" thingy in shell scripts when I want to first write something to the temporary file with multiple programs and then read content of the file from another program, but you don't want that temporary file just sit on your disk or in /tmp eating memory. Create temporary file with mktemp, then call `exec 3>/tmp/tmpfile ; exec 4

[@prospermatkovic5559]

Excellent! But would be even better if contrasted with how multiple threads manage open file descriptors. A simple drawing showing the file descriptors table and its relation to open files table would make it more clear why closing a descriptor in a parent/ child does not necessarily remove the file from the open files table

[@avhd187]

Forking around with files. Say it ten times as fast.

[@alejandroulisessanchezgame6924]

Hi do you have any video in your channel explaining how to use malloc with a variable string input from console

[@capability-snob]

details of the posix standard would make a great category for trivial pursuit. > the colour of the cheese is undefined within a signal handler.

[@fennecfox2366]

Fun fact, the buffering example looks different if you use terminals instead of regular files. The buffering will default to line buffering instead of fully buffered.

[@shantanushekharsjunerft9783]

fopen returns a pointer to FILE. That means both parent and child should have the same pointer address. If one closes the FILE using that pointer, then the struct in the heap ought to be kaput. Very surprised to see that was not the behavior. I am guessing “fclose” is what we really need to understand

[@vento9943]

IIRC in fork(), the kernel copies the FDs / kernel structures corresponding to those FDs

[@anon_y_mousse]

This is why you shouldn't share such things directly with child processes. Good lesson for people to learn. As for the hardcoding of string sizes, you could write a macro to make it easier to share a string literal. I would suggest making the macro on the whole function call, because different functions will take things in different orders dependent on the library or platform you're using.

[@redabou9al562]

it's simple, child inherits fds table from the parent and will have its own fd table copy

[@rogo7330]

Your explanation not complete. They literally share the same file descriptors, with cursors and, I presume, flags. This can be undesired behaviour if you wanted two of processes have the same file oppened, but cursors be separate. For example, if one process will write to the file, and other will read what was written to this file. To do that you need to open file twice, I did not found a way to dup file descriptor in a way that they will become two separate entities; dup and dup2 just assigns a new number for the same file descriptor entity that have shared cursor.

[@lawrencedoliveiro9104]

The POSIX spec talks about “file descriptors” versus “file descriptions”. The “file descriptors” are those small non-negative integers a process uses to refer to its “file descriptions”. The “file descriptions” are the objects the kernel maintains for keeping track of those open files. When a process forks, it gets its own file descriptor table, but those file descriptors point to the same file descriptions. File descriptions are never cloned; there is no POSIX API call which has the effect of cloning/duplicating a file description.

[@tawheedcoopoosamy9329]

This guy is the Matthew Mcconaughey of programming

[@scorpion7256]

What a title 😂😂

[@jamesdurham9027]

This might mot work in windows style OS's. of course Windows doesn't do fork, but I think open file handle's might not be shareable between concurrent processes.

[@lawrencedoliveiro9104]

Lots of things don’t work with Windows. Windows was created by Dave Cutler, who was a Unix hater.

[@bramfran4326]

cool and dangerous!

[@andresj89]

I definitely read that thumbnail wrong...

[@lawrencedoliveiro9104]

What does this code do: class ImTheChild(Exception) : def __init__(self, to_parent) : self.args = ("I am a child process!",) self.to_parent = to_parent ♯end __init__ ♯end ImTheChild def spawn_child() : from_child, to_parent = os.pipe() child_pid = os.fork() if child_pid != 0 : os.close(to_parent) else : os.close(from_child) raise ImTheChild(to_parent) ♯end if return \ from_child, child_pid ♯end spawn_child to_parent = None try : children = [] for i in range(nr_children) : from_child, child_pid = spawn_child() children.append \ ( { "pid" : child_pid, "from_child" : from_child, } ) ♯end for except ImTheChild as excp : ♯ parent continues with loop, child doesn’t children = None to_parent = excp.to_parent ♯end try

[@ewrietz]

First

[@kuyajj68]

2nd

[@sirynka]

​3rd

[@fromant65]

This sounds like chess