5 ms·

> ... 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 readin

> ... 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.

Viper007Bond 9y ago
Interestingly PowerShell is petty awesome in that regard. You pass around objects instead of trying to parse strings and things.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- vardump 9y ago
  PowerShell is not Windows API, win32 is. So your comment makes little sense.
- reificator 9y ago
  Powershell is just that, a shell. I agree that Powershell itself is pleasant enough to use but that's not what's being discussed.
- msla 9y ago
  > You pass around objects instead of trying to parse strings and things. That can't be very good for debuggability.
  - pzone 9y ago
    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.
    - msla 9y ago
      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.
- sleepydog 9y ago
  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 http://cr.yp.to/docs/selfpipe.html [2]: http://man7.org/linux/man-pages/man2/signalfd.2.html http://man7.org/linux/man-pages/man2/signalfd.2.html
deleted 9y ago
[deleted]
derefr 9y ago
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.
- pavlov 9y ago
  > ... message-passing IPC all the way down Wasn't QNX like that?
  - dfox 9y ago
    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.
my123 9y ago
The NT Native API is relatively elegant, especially Alpc (a shame that it's mostly hidden by Win32 tho)
- vardump 9y ago
  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.
henesy 9y ago
Plan 9?

Viper007Bond 9y ago

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

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
vardump 9y ago
PowerShell is not Windows API, win32 is. So your comment makes little sense.
reificator 9y ago
Powershell is just that, a shell. I agree that Powershell itself is pleasant enough to use but that's not what's being discussed.
msla 9y ago
> You pass around objects instead of trying to parse strings and things. That can't be very good for debuggability.
- pzone 9y ago
  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.
  - msla 9y ago
    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.
sleepydog 9y ago
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 http://cr.yp.to/docs/selfpipe.html [2]: http://man7.org/linux/man-pages/man2/signalfd.2.html http://man7.org/linux/man-pages/man2/signalfd.2.html

deleted 9y ago

[deleted]

derefr 9y ago

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.

pavlov 9y ago
> ... message-passing IPC all the way down Wasn't QNX like that?
- dfox 9y ago
  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.

my123 9y ago

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

vardump 9y ago
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.

henesy 9y ago

Plan 9?