Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A fork() in the road

microsoft.com

Post reply on HN
Print view View original

151–160 of 184 posts

Re: A fork() in the road

#151

Post by IshKebab »

ktpsns wrote: post #68

Can anybody elucidate about why fork() is still used in Chromium or Node.js? They are not old-grown traditional forking Unix servers (unlike Apache or the mentioned databases in the paper). I would expect them to implement some of the alternatives and having fork() only as a fallback in the code (i.e. after a cascade of #ifdefs) if no other API is available. Therefore, I wonder where the fork() bottlenecks really app…

This is explained in the paper. It's to get access to copy-on-write memory so you can make a pre-initialised process cheaply.

Re: A fork() in the road

#152

Post by IshKebab »

fopen64 wrote: post #96

When I learnt how fork() and select() worked, I just felt in love with Unix. The Win32 API was so ad-hoc and unnatural in direct comparison.

You fell in love with Unix because of a hacky unintuitive syscall? I'd suggest reading the paper!

Re: A fork() in the road

#153

Post by IshKebab »

cryptonector wrote: post #150
zbentley wrote: post #97

While fork() might be sub-optimal for launching different programs (fork() + exec() vs. posix_spawn()), it's absolutely essential in several types of common systems that don't use it to launch different programs. Fork-requiring program class 1: The biggest example where fork() is needed are webservers/long-running programs with significant unchanging memory overhead and/or startup time. Many large applications writte…

There is one case where fork() is fantastic: as a way to dump a core of a running process while leaving the process running -- just fork() and abort()! But even this case should be handled by having something like gcore(1). Another common use of fork() for things other than exec()ing is multi-process services where all will keep running te same program. Arranging to spawn or vfork-then-exec self and have the child re…

These are both mentioned in the paper.

Re: A fork() in the road

#154

Post by IshKebab »

zzzcpan wrote: post #91

It's hard to take them seriously when they imply the mess that threads are is somehow acceptable and necessary, but nicer, less error prone and simpler fork isn't. Threads are a nasty hack and a liability for the modern programmer to use. And systems researchers really should acknowledge that their continued existence as first class OS primitives is holding back systems research much more, than fork. I guess they are…

What's wrong with threads exactly?

Re: A fork() in the road

#155

Post by dblohm7 »

cryptonector wrote: post #128
JdeBP wrote: post #81

Earlier quoted context omitted.

There has been a lot of discussion in recent years about how cheap that "cheaply" really is. * https://news.ycombinator.com/item?id=9653238 * https://news.ycombinator.com/item?id=18071278 * https://news.ycombinator.com/item?id=19622503

Yeah, it's not really cheap at all. However! vfork() is cheap, very very cheap, though, of course, you then have to follow it up with an exec(), and the cost of that on Windows depends on the setup cost of the executable being exec'ed. Part of the problem is the DLLs, as many have mentioned, and also the fact that each statically links in its own CRT (C run-time). The shared C run-time MSFT is working on should help…

> Part of the problem is the DLLs, as many have mentioned, and also the fact that each statically links in its own CRT (C run-time)

No, that isn't the case on DLLs shipped with Windows.

Re: A fork() in the road

#156

Post by naasking »

stirfrykitty wrote: post #142
naasking wrote: post #124

Earlier quoted context omitted.

Microsoft Research is not Microsoft. Microsoft Research employs some of the main Haskell developers, and you don't see Haskellers going all conspiracy theory. Research is research, and either the ideas they describe are good and should be adopted, or they're bad and should be ignored.

This may be true, but I don't want MS having ANY say on what goes into a Linux or FreeBSD OS. None. They have an agenda that doesn't fit in well with FOSS. May no mistake about it, driving everything so that it works with Azure/VS, whatever, is about staying relevant in a world that is largely leaving them behind. Short of having to write PS at work (required), I haven't run anything MS at home since 1998 and have no…

> This may be true, but I don't want MS having ANY say on what goes into a Linux or FreeBSD OS. None. They have an agenda that doesn't fit in well with FOSS.

False. MS is now one of the leading FOSS contributors. You're living in the past.

Re: A fork() in the road

#157

Post by bloak »

zaarn wrote: post #66
bloak wrote: post #63

Earlier quoted context omitted.

"If one crashes, a new one is spawned." I suppose that makes sense on an OS on which crashing is expected behaviour, though some people would want to know what bug caused the crash and whether that bug has security implications.

Crashing is an expected behaviour in Linux as well, you can enable coredumps or utilize an applications log if you want to know why.

The Linux kernel doesn't crash much, unless you have dodgy drivers or dodgy hardware. Whether your userland programs crash or not depends on what you're running. I don't expect to see sshd crashing, for example, though it's true that almost any program will exit suddenly if the system runs out of memory, which to an ordinary user looks like a crash, though it's a very different thing really.

Re: A fork() in the road

#158

Post by cryptonector »

dblohm7 wrote: post #155
cryptonector wrote: post #128

Earlier quoted context omitted.

Yeah, it's not really cheap at all. However! vfork() is cheap, very very cheap, though, of course, you then have to follow it up with an exec(), and the cost of that on Windows depends on the setup cost of the executable being exec'ed. Part of the problem is the DLLs, as many have mentioned, and also the fact that each statically links in its own CRT (C run-time). The shared C run-time MSFT is working on should help…

> Part of the problem is the DLLs, as many have mentioned, and also the fact that each statically links in its own CRT (C run-time) No, that isn't the case on DLLs shipped with Windows.

But it is for 3rd party DLLs.

Re: A fork() in the road

#159

Post by the_why_of_y »

zzzcpan wrote: post #119
arghwhat wrote: post #112

Earlier quoted context omitted.

> Ummmm. No. Threads are a much harder API to get right. Ummmm. No. Threading is not a hard API to get right. It's very simple: You get a new executing thread in the same memory space. You can create them whenever you like without any side-effects. Now, don't trample on your memory. Read all you want from anywhere. If you want to write to shared memory, ensure both reads and writes are behind a mutex, or learn about…

> but now you have to establish some form of IPC Shared memory for threads is a form of IPC too, except one where it's very easy to make a mistake, introduce concurrency bugs. > I also certainly cannot see any sensible argument for threading being harder than fork() You should read a paper or two on concurrency bugs. Including on those using explicit but shared communication channels, like CSP does.

Concurrency bugs can be eliminated with state of the art static analysis (see Rust, Pony) - with the exception of deadlocks, which you can easily introduce with multiple processes as well.

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

Re: A fork() in the road

#160

Post by dfawcus »

alkonaut wrote: post #55
localhostdotdev wrote: post #53

"every other system has a feature except us, and we are not going to add it (because reasons) even if it's very widely used" also: > When a fork syscall is made on WSL, lxss.sys does some of the initial work to prepare for copying the process. It then calls internal NT APIs to create the process with the correct semantics and create a thread in the process with an identical register context. Finally, it does some add…

They must have considered it many times (not least when making the partial posix support for NT) but felt that supporting it wouldn’t help deprecating it either. AFAIK it’s only unix/Linux (posix) OSes that implement fork. Perhaps that’s what you meant by “every other system”, ie unix + clones/derivatives?

Also DRI's FlexOS 2.2 had it, it was not a unix clone per-se.

The COMMAND SVC had/has 4 variants:

- Execute program (akin to posix_spawn)

- Chain program (akin to posix_spawn, and parent exit)

- Execute subprocess (start a thread, one supplies code + stack address)

- Execute fork process (ala fork, but one supplies code + stack address like with 'subprocess' above)

Originally it only had the first two forms, 2.1 added the subprocess form, 2.2 added the fork form.

It didn't have a direct equivalent to exec(), but did have an OVERLAY SVC which loaded fresh code in to the process, and I expect that could be used to make something like exec(). Not that I ever tried, given there was no real need for it.

The other way to create an exec() like behaviour would have been with the CONTROL SVC, akin to ptrace(), but that would have been painful to do.

Post reply on HN