Hacker News Reader

Comment by ansible | Hacker News Reader

> ... POSIX is not so great as well ...

Ugh, tell me about it. Just dealing with a relatively simple situation where you've got signals coming in while reading a pipe is a hassle to get completely correct.

I am so there for an operating system API that is relatively simple and sane. Where writing correct programs is, if not the easy path, at least not the hard and obscure path.

View on HN

I'd be down for an Erlang-like OS ABI (or, to put that another way, a Windows-GUI OS ABI, but for even non-GUI processes): just message-passing IPC all the way down. OS signals, disk IO, network packets, [capabilities on] allocated memory, [ACL'ed] file handles, etc: all just (possibly zero-copy) messages sitting in your process's inbox.

Of course, it's pretty hard to deal with a setup like that from plain C + libc + libpthread code, so OSes shy away from it. But if your OS also has OS-global sandboxed task-thread pools (like macOS's libdispatch)—and people are willing to use languages slightly higher-level than C where tasks built on those thread-pools are exposed as primitives—then it's not out of the question to write rather low-level code (i.e. code without any intermediating virtual-machine abstraction) that interacts with such a system.

> ... message-passing IPC all the way down

Wasn't QNX like that?

QNX IPC mechanism is essentially cross-process function call, ie. message sender is always blocked while waiting for message reply and the server process cannot meaningfully combine waiting for message and some other event.

Edit: in essence QNX messages work like syscalls, with the difference that there are multiple "systems" that accept "syscalls". For what it's worth Solaris has quite similar IPC mechanism that is mostly unused.

The NT Native API is relatively elegant, especially Alpc (a shame that it's mostly hidden by Win32 tho)

The biggest blunder is that ALPC is not accessible through Win32 at all. ALPC is much more sane than any other IPC Windows got.

Sure, you can use ALPC, but only by using undocumented unstable NT API...

Sigh.

Plan 9?

Interestingly PowerShell is petty awesome in that regard. You pass around objects instead of trying to parse strings and things.

PowerShell is not Windows API, win32 is. So your comment makes little sense.

Powershell is just that, a shell. I agree that Powershell itself is pleasant enough to use but that's not what's being discussed.

> You pass around objects instead of trying to parse strings and things.

That can't be very good for debuggability.

Type checking and calling help methods can be useful for debuggability! If you want to figure out what you're looking at in string format, call its .ToString method.

Adding extra complexity just means more to go wrong. Plain text can't really go wrong because anything can use it, anything can edit it, anything can show it. With "objects" I'm betting that Powershell itself never fails.

I don't think that's what the parent was complaining about, it was more about handling signals correctly. It's incredibly easy to write buggy signal handlers on a Linux system. The "self-pipe" trick[1], and later, signalfd(2) have made signal handling much easier, but a lot of programs still do it the old way.

[1]: http://cr.yp.to/docs/selfpipe.html [2]: http://man7.org/linux/man-pages/man2/signalfd.2.html

Reply on news.ycombinator.com