Hacker News Reader

Comment by pjc50 | Hacker News Reader

Really POSIX should just acquire CreateProcess and have done with the problem. It's the API you generally want when starting a new, unrelated program. Probably for POSIX you'd want to allow specifying which handles become the new process stdin/stdout/stderr, since Windows handles consoles in a stranger, less convenient way.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

View on HN

They do have it. It's called `posix_spawn`[0]. Most systems implement it using clone/execve I assume.

[0] http://pubs.opengroup.org/onlinepubs/009695399/functions/pos...

It doesn't matter which thing you do here. Almost all of NT is like that, if there's a feature you're sure NT has that Linux doesn't have, or vice versa, usually either you're wrong or the relevant team is working frantically to correct this mistake.

fork()/clone() obliges you to track which things the child doesn't want from the parent, and have a way to override them

CreateProcess obliges you to track which things the child DOES want from the parent, and have a way to override them.

There's a convergent evolution at work, the same way bats and birds have both got wings without a common ancestor having wings, wings work, not quite the _same_ wings, but the idea works, so it's inevitable.

futex() and WaitOnAddress have the same funhouse mirror effect. They're doing the same exact thing (very, very cheap synchronisation primitive, with just barely enough features to be useful), the names and descriptions are really different, but if you use both you're like "Oh, these are basically the same, huh". Both names are equally useless, futex() is a clever name if you already know what it does, but until you do you've no idea what to look for. On the other hand WaitOnAddress doesn't actually er, wait on an address, that would be expensive, like futex waking it up when something changes is _your_ job as the programmer.

WIN32 has a number of far, far superior features though, such as WaitForMultipleObjects(), Security Descriptors and Access Tokens, and SIDs. And its event system is like *BSD kqueue and Illumos event ports (i.e., it doesn't suck), while Linux's epoll() is... well, a disaster.

Yes, but the distinction between "must enumerate things to child" and "child inherits everything" isn't symmetrical. I believe that it's better for security and reliability if the list is made explicit, but evidently not everyone agrees.

What happens if you want the child to inherit other fds? Or set other attributes such as the session, euid, egid etc?

The elegance of fork() is in avoiding the complexity of requiring every attribute of the process to be explicitly stated in order to create a new process. We simply inherit our parent's attributes and if that turns out not be desirable it is fixed in the child with the usual syscalls.

EDIT: s/And/Or set/

Your "avoiding the complexity" in fact turns into its mirror image: in order to ensure sane behaviour, you have to have a preamble to avoid inheriting things you don't want. This results in people writing things like http://www.linuxprogrammingblog.com/threads-and-fork-think-t... : the list of things you have to remember not to use in order to use the "elegant" API.

I'm not positive that it's elegant. It may also be considered an ugly hack (not sure either), and I'm pretty certain it's been responsible for many security holes.

It would be interesting to see in what ways Unix (especially shell scripts) would be different if processes would not inherit all the baggage by default.

There's a very, very fine line between an elegant solution and an ugly hack.

It may be not fine (your sarcasm was noted) but I still don't see it in this instance.

Attributes is just another word for "global state". When we speak of elegance in computing, it often means functional programming languages where eradicating global state is the primary motivation.

So really fork is the opposite of elegance. It makes state implicit, not explicit.

That may have been fine in 1970, when there was very little to inherit (no thread handles, no named pipes, no semaphores, IIRC) and security wasn’t a big concern.

Nowadays, I think ‘whitelisting’ what the new process can do is the choice to make, not forking and then (hopefully) ‘blacklisting’ what you don’t want (that’s especially important if you eventually will be running code you didn’t write or, maybe, don’t even have source for)

That also is easier to test for. If you forget to specify a capability before forking, the bugs you see will be better reproducible than when you forget a thing you don’t need.

I can’t find it now, but try googling an article on how to properly fork a process nowadays. It is insanely difficult to do right.

Reply on news.ycombinator.com