Hacker News Reader

Comment by hyperman1 | Hacker News Reader

Has anyone an example for wanting to fork? Most use cases seem covered by either threads or fork+exec process spawning.

The example given by the author:

  make it practical to introduce concurrency after development, rather than designing it in from the start

seems risky to me: Even if you're safe from other threads, there is a lot of other unknown state like fd's still inherited. And concurrency can be introduced after development, e.g. by using message passing. So going all the way threaded or re-execing yourself seem both safer to me with no real downsides.

View on HN

One of the available garbage collector implementations in D (version 1) (and there's a work in progress to port it to D2) is a concurrent garbage collector which performs a mark phase in forked process going over the address space.

Also I've seen a project which persists large amounts of data to disk by forking and using a consistent snapshot of the data structures (which the new process will not mutate, so there's no need for locking).

> One of the available garbage collector implementations in D (version 1) (and there's a work in progress to port it to D2) is a concurrent garbage collector which performs a mark phase in forked process going over the address space.

I'm pretty skeptical of that approach. If there's heavy churn, the copy-on-write behavior means that the mark phase _increases_ memory use, when presumably you're doing GC because you need to _decrease_ memory use. And I assume there's some cost to these VM manipulations in general. Is this implementation competitive with other D garbage collectors in terms of memory usage, CPU time, latency, etc? are D's garbage collectors in general competitive with those of Go and Java?

> Also I've seen a project which persists large amounts of data to disk by forking and using a consistent snapshot of the data structures (which the new process will not mutate, so there's no need for locking).

It isn't an uncommon strategy. For example, the Factorio dedicated server can (optionally) do that if you're running it on non-Windows. The performance is great, but it's marked as experimental, probably because of issues like this article describes.

Redis background saving works like that too.

https://redis.io/topics/faq#background-saving-fails-with-a-f...

I used to work on a system that processed lots of batch jobs. The jobs themselves were built to run inside of a software framework because they needed to be customized for different purposes but still had lots of common needs.

So we had a process that would start up, initialize the framework, then look for jobs to run. For each job, it would fork, giving the job an initialized framework but also giving jobs some isolation.

Android does something similar:

"Each app process is forked from an existing process called Zygote. The Zygote process starts when the system boots and loads common framework code and resources (such as activity themes). To start a new app process, the system forks the Zygote process then loads and runs the app's code in the new process. This approach allows most of the RAM pages allocated for framework code and resources to be shared across all app processes."

( https://developer.android.com/topic/performance/memory-overv... )

fork() is not required for this. On Apple platforms the dyld shared cache performs the same function: all processes share the same copy of libSystem, Foundation, etc.

Most platforms with dynamically-loaded shared libraries do something similar. However, that only avoids having multiple copies of the library code and read-only data in memory—each process still has to run its initialization code separately, parsing configuration files, setting up global variables, etc., and any data which is written during initialization but read-only for the rest of the program is not shared. The Zygote model allows the system to perform this initialization just once and share the results with any number of child processes.

I believe the Apache web server's Prefork MPM module does something similar—fork() allows the server to spin up new child processes in a pre-initialized state, ready to respond to requests. Servers in general tend to be a good fit for this style of execution.

So redesign your software to allow storing the results of initialization code having run, configuration files having been parsed, global variables having been set up, and so forth in a loadable library (or in some other mmappable file).

Emacs works this way, because it has a lot of Lisp code to load in and compile and doesn't have a central daemon (and even if it did, it would want to avoid recompiling the code when the computer is rebooted.) The compiled C binary "temacs" is instructed to load and evaluate a bunch of Lisp and then more-or-less coredump itself in an orderly way to a binary called "emacs"; when that binary is run, everything is in memory as if you had forked temacs after initialization. https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...

For your average server process reading config files, it probably suffices to have a "compiled" form of the config files in Cap'n Proto or some similar format that is directly usable as in-memory structures, and mmap that in. (Or perhaps just actual native data structures, if the format doesn't need to have a stable representation across versions of your software.)

I run an online game that has has instanced multiplayer.

We have a single process on each server that starts up and loads every single game resource. After this is waits for requests from the instance manager to create new instances. As new instances are required, this "spawner" process fork()s to create one.

Each process uses less memory because all the loaded resources the game needs to run are shared between all the copies.

You also get slightly faster performance because commonly used data still in the CPU cache when switching between processes.

If we used a thread per instance, then we wouldn't have crash isolation between the different game instances, which is handy.

It's also possible to explicitly mmap a shared memory segment to load resources in that without using fork()s copy on write, but it's just more tricky, and the fork() method is totally robust no matter what code other programmers might write.

The American Fuzzy Lop fuzzing tool can use fork to speed up fuzzing by avoiding the overhead of repeatedly initializing processes: https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-withou...

Forking from a setup environment n times is much faster than setting said environment up n times (=fork+exec)

If you spawn, you can set up different process descriptors. Not all properties need to be inherited in all circumstances.

That doesn't seem like much of a rebuttal for the case where you want to inherit more than just descriptors.

A classic example is daemonizing a process. While still attached to the terminal you first parse command-line options, read config files, and do some sanity checks. Any errors caught at this point cause an error message and exit(1). Otherwise fork+setsid to detach from the session, then fork again to lose the new session leader.

Apart from that, the only thing I have used fork for (apart from fork+exec) is doing concurrent blocking I/O while prototyping, before rewriting the code to use non-blocking I/O with no forking.

Copy-on-write semantics can be pretty useful. You've built up a large in-memory graph and want to execute a destructive or long running query on the data set in the background (e.g., write it out to media when the main process MUST continue to service requests), you want to generate a snapshot core without exiting, etc. etc.

I don't classify these use cases are concurrency-after-development cases. Lots of systems use this to do interesting things.

> The example given by the author seems risky to me

Ages ago I made a DNS server, and near the top of the program was a simple:

    for(i=0;i<ncpus;++i)if(!fork())break;

> Most use cases seem covered by either threads or fork+exec process spawning.

Most of the use cases of threads are covered by fork+explicit mmap/vm_remap.

A "shared-nothing" will also contain less code, and having no need for lock/unlock keeps a lot of spam invalidations away from the memory controller making it for many tasks faster.

> Even if you're safe from other threads, there is a lot of other unknown state like fd's still inherited.

The problems you get with threads are bigger.

http://geocar.sdf1.org/close.html

I'm open to arguments, but right now I feel that threads are (for many uses cases) a poor man's fork. Like threading, forking gives you concurrency but unlike threading it also gives you isolation. There are plenty of IPC mechanisms available to communicate things back and forth when you need to.

Right, and forks are poor man's processes. All of them have pros and cons but I think forks are only useful for very exotic use cases.

> unlike threading it also gives you isolation.

If you want isolation why not launch processes? With forks, that copy-on-write thing can increase total RAM usage by a huge factor, if the parent process writes to RAM a lot.

> There are plenty of IPC mechanisms available to communicate things back and forth when you need to.

For communicating gigabytes of data back and forth you want shared memory anyway.

And even for small messages, with threads IPC is faster (1) they are in the same address space, TLB stays current, context switches are faster (2) In some cases, shared memory enables more efficient user-mode IPC methods like busy waiting and lock-free stuff.

All fair points. I didn't really consider creating processes in a non-fork way. I'd probably miss the easy transfer of unnamed shared objects you get with forking. How do unrelated processes usually initiate communication?

> How do unrelated processes usually initiate communication?

They aren't unrelated, they are parent and child. They know PIDs of each other. Parent can read/write stuff to child's streams, input output error. Child inherits opened files. Parent can set command-line arguments & environment variables for the child.

> For communicating gigabytes of data back and forth you want shared memory anyway.

Not really. You are better off communicating what to do with the data, rather than sharing the data.

> You are better off communicating what to do with the data, rather than sharing the data.

Not if you actually want to distribute the work over several cores.

Example: Your data is partitioned into 4 segments A, B, C, and D. In step 1, node X processes A&B and node Y processes C&D; in step 2, node X processes A&D and node Y processes C&B. If A, B, C, and D are large, this is a prime example where shared memory trumps message passing in terms of performance. If you think that's a contrived case: dense matrix multiplication behaves like this.

Only if you don't have a data-parallel workload. Message passing is often a nonstarter for data-parallel workloads.

Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it?

> Another way to look at it is that the hardware has a very efficient word-level message-passing interface built-in, via shared memory. Why not take advantage of it?

Because shared mutable state is the root of all evil, or at least very difficult to reason about. Better to have clear owners for all state; if you need to conduct multiple operations on the same data you should move the code to where the data is rather than sharing the data between different processing units (this has long been a truism of distributed system design; modern multicore processors behave much the same as distributed systems if you zoom in enough, and the same techniques are appropriate).

It may be "the root of all evil", but often there's no faster way to solve the problem. We need to accept that shared mutable state is sometimes necessary and work on how to tame it to be maintainable and usable.

Shared mutable state is like goto; yes, it is sometimes necessary, but that only happens when there's a deficiency in your language's concurrency primitives.

If you have a dependency for every function, you have slow start up times. If you also have a unit test for every function, you have a very slow test cycle. You can mitigate this by forking after startup. Can't use threads because they don't provide isolation between tests.

I’ve found fork useful for Python multiprocessing. To reduce the overall memory usage. But this is an ancient solution to an ancient problem in the first place.

Seems like the GIL is still a very modern problem with ancient solutions not yet realized by python runtimes. What you want is threads, but you can’t use them. Bummer. Other language runtimes don’t have that problem.

https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c...

You could also fork out a pool at start time, before creating any threads.

This is the well known and only not broken solution. Im glad ive read it finally

Reply on news.ycombinator.com