How does fork work with open files?

---
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:

***

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:

To Support the Channel:
+ like, subscribe, spread the word

[godnyx]

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!

[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

[rogo]

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</tmp/tmpfile` and then just delete that temporary file with `rm`. Because this file still opened by this shell script, its content still preserved by the kernel and you can write to it through fd 3 and read from it through fd 4, but the file path is already free and this file will be "garbage collected" automatically after shell dies for any reason. You need to open two separate file descriptors because if you open the file with `exec 3<>/tmp/tmpfile`, writing and reading operations will share the same cursor, and reading will return you nothing. Separating them allow two cursors advance separatly in the same file.

[davidx]

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

[nunyobiznez]

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

[esrxa]

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

[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!

[mynameistrez]

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

[unperrier]

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

[prospermatkovic]

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

[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.

[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.

[avhd]

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

[fennecfox]

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.

[alejandroulisessanchezgame]

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

[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.

[shantanushekharsjunerft]

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

[tawheedcoopoosamy]

This guy is the Matthew Mcconaughey of programming

[redaboual]

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

[jamesdurham]

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.