3 ms·

Is this what you want most of the time? If you're just going fork() && exec() then why would you copy all that state just to run some subprogram? Is that what

by geocar 9y ago

Is this what you want most of the time? If you're just going fork() && exec() then why would you copy all that state just to run some subprogram? Is that what you want any of the time? This prefork implementation is silly. Either do prefork after initialisation so you can take the benefits of COW, or don't bother: Just use SO_REUSEPORT and run 10 copies of your server. This distributes the TCP traffic and provides you an excellent way to upgrade-in-place (just roll up the new version as you roll-down old ones).

mhandley 9y ago
I agree - most of the time, the current fork() implementation is what you want, so it's the right choice. The conventional wisdom is that you shouldn't spawn threads and then fork(), and so long as you stick to this, you're fine. Today though, everyone loves threads. It's hard to know precisely what happens in some low-level library, so it's hard to be sure that you don't have any threads left running after initialization. This is the subject of the OP. My question though is broader - if we chose, could we add a version of fork() that did clone all the threads? I'm not entirely sure what it would be used for, but I'm sure there would be uses. Likely some of those would be for increased security, as processes provide stronger isolation.
- geocar 9y ago
  > I'm not entirely sure what it would be used for, but I'm sure there would be uses. I suspect strongly there aren't. One of the biggest problems you have to contend with is around mutexes (and the like) and their state. If you copy them, we double-book an external-resource (like storage or something), and if you don't we almost certainly deadlock. Another is any thread waiting on a resource (like reading a file descriptor) or writing to the disk (do you write twice?) and so on.
gcb0 9y ago
because that what everyone that uses fork want. memory access. otherwise they would use posix_spawn or something

by geocar 9y ago

mhandley 9y ago

I agree - most of the time, the current fork() implementation is what you want, so it's the right choice. The conventional wisdom is that you shouldn't spawn threads and then fork(), and so long as you stick to this, you're fine. Today though, everyone loves threads. It's hard to know precisely what happens in some low-level library, so it's hard to be sure that you don't have any threads left running after initialization. This is the subject of the OP. My question though is broader - if we chose, could we add a version of fork() that did clone all the threads? I'm not entirely sure what it would be used for, but I'm sure there would be uses. Likely some of those would be for increased security, as processes provide stronger isolation.

geocar 9y ago
> I'm not entirely sure what it would be used for, but I'm sure there would be uses. I suspect strongly there aren't. One of the biggest problems you have to contend with is around mutexes (and the like) and their state. If you copy them, we double-book an external-resource (like storage or something), and if you don't we almost certainly deadlock. Another is any thread waiting on a resource (like reading a file descriptor) or writing to the disk (do you write twice?) and so on.

gcb0 9y ago

because that what everyone that uses fork want. memory access. otherwise they would use posix_spawn or something