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

How the Windows Subsystem for Linux Redirects Syscalls

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

181–190 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#181

Post by j_s »

madez wrote: post #106
tacos wrote: post #100

Earlier quoted context omitted.

Hey everyone, we found him!

I don't want to take sides in this discussion but share an anecdote. Hey, maybe even someone knows a solution for this. I have a PC connected via on-board HDMI to a Denon AVR solely for the purpose of getting the audio to the amplifier. Windows doesn't let me use that audio interface without extending or mirroring my desktop to that HDMI port. Since there is no display connected to the AVR I don't want to extend the…

If I remember correctly, NVIDIA did a decent job with their on-board HDMI driver audio-wise; what brand is yours? I'm 100% the functionality is dependent on the driver rather than the OS.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#182

Post by bitwize »

wahern wrote: post #172
trentnelson wrote: post #151

Earlier quoted context omitted.

Let me rephrase it: there is nothing on any version of UNIX that supports an asynchronous file I/O API that integrates cleanly with the file system cache -- you can do signal based asynchronous I/O, but that isn't anywhere near as elegant as having a single system call that will return immediately if the data is available, and if not, sets up an overlapped operation and still returns immediately to the caller. This i…

They're called threads. Overlapped I/O on Windows is based on a thread pool, which is why you can't cancel and destroy your handle whenever you want--a thread from the pool might be performing the _blocking_ I/O operation, and in that critical section there's no way to wake it up to tell it to cancel. Just... like... on... Unix. The difference between Windows Overlapped I/O and POSIX AIO is that on Windows it's a bla…

The difference between Windows Overlapped I/O and POSIX AIO is that on Windows it's a black box, so people can pretend it's magical.

No. The difference is that in Windows you can check for completion and set up an overlapped I/O operation in one system call. Requiring multiple system calls to do the same thing means more unnecessary context switches, and the possibility of race conditions especially in multithreaded code. That and, as trentnelson stated, the Windows implementation is well integrated with the kernel's filesystem cache. Linux userspace solutions? Hahaha.

Supplying this capability as a primitive rather than requiring userland hacks is the right way to do it from an application developer's perspective.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#183

Post by bitwize »

jsmeaton wrote: post #133
niels_olson wrote: post #125

Earlier quoted context omitted.

Here's a nice graphical comparison of syscalls between Linux and Windows http://www.visualcomplexity.com/vc/project.cfm?id=392 Are you saying the Windows flow looks like spaghetti only because the software tested software (Apache) wasn't designed for Windows?

The second image is of IIS running on Windows, not Apache. Different software on different OSes. Regardless, it doesn't seem like parent is making the argument that the NT kernel isn't complicated - just that it is superior.

It is more complicated because -- surprise -- I/O usage patterns do not fit in one neat little box, and you have to provide special handling of special cases that do occur frequently in the real world.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#184

Post by uudecode »

bitwize wrote: post #46
ataylor284_ wrote: post #38

> The real NtQueryDirectoryFile API takes 11 parameters Curiosity got the best of me here: I had to look this up in the docs to see how a linux syscall that takes 3 parameters could possibly take 11 parameters. Spoiler alert: they are used for async callbacks, filtering by name, allowing only partial results, and the ability to progressively scan with repeated calls.

This is a recurring pattern in Windows development. Unix devs look at the Windows API and go "This syscall takes 11 parameters? GROAN." But the NT kernel is much more sophisticated and powerful than Linux, so its system calls are going to be necessarily more complicated.

"... so its system calls are going to be necessarily more complicated."

Are you implying that an increase in "power" can never be achieved through increasing simplicity?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#185

Post by CamperBob2 »

1024core wrote: post #143
trentnelson wrote: post #98

Earlier quoted context omitted.

Curiosity got the better of me recently when I re-read Russinovich's [NT and VMS - The Rest Of The Story]( http://windowsitpro.com/windows-client/windows-nt-and-vms-re... ), and I bought a copy of [VMS Internals and Data Structures]( http://www.amazon.com/VAX-VMS-Internals-Data-Structures/dp/1... ). Side-by-side, comparing VMS to UNIX, and VMS's approach to a few key areas like I/O, ASTs and tiered interrupt levels a…

The joke used to be: VMS++ --> WNT

Yep, that'd be the spiritual predecessor to Bing Is Not Google.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#186

Post by trentnelson »

inopinatus wrote: post #146
bitwize wrote: post #83

Earlier quoted context omitted.

Actually it does, as it mentioned that the extra parameters are for things like async callbacks and partial results. The I/O model that Windows supports is a strict superset of the Unix I/O model. Windows supports true async I/O, allowing process to start I/O operations and wait on an object like an I/O completion port for them to complete. Multiple threads can share a completion port, allowing for useful allocation…

Based on what you describe here, I'd say your comparative understanding is about two decades out of date. Async I/O has been a capability in various Unix and Unix-alike kernels for that long.

As in signal based AIO? Have you ever tried to use it in a high performance network server, where you want to have reads also satisfied from the cache if possible?

Because that is like pulling teeth on UNIX. See: https://groups.google.com/forum/#!topic/framework-benchmarks...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#187

Post by bitwize »

uudecode wrote: post #184
bitwize wrote: post #46

Earlier quoted context omitted.

This is a recurring pattern in Windows development. Unix devs look at the Windows API and go "This syscall takes 11 parameters? GROAN." But the NT kernel is much more sophisticated and powerful than Linux, so its system calls are going to be necessarily more complicated.

"... so its system calls are going to be necessarily more complicated." Are you implying that an increase in "power" can never be achieved through increasing simplicity?

That's the thing. Just by glancing at the API docs, Windows looks more complicated but where the rubber meets the road in terms of real high-performance application development, Windows is way simpler. In Windows you can do in one syscall what would take several in Linux. You can schedule I/O calls across multiple threads in a completely thread-safe manner without having to manage the synchronization yourself -- and since threads go to sleep entirely while waiting for I/O operations to complete, there is no chewing up CPU cycles in a select/epoll loop. So yes, writing "hello world" or simple filters is simpler in Unix -- but writing multithreaded server applications that maximize throughput is simpler in Windows.

Unix is bristling with features designed to "allow you to save me some time". It was designed to make it easy to write quick, "one-off" programs in C. VMS -- the predecessor to Windows NT -- was designed to run long-lasting, high-performance, high-reliability business applications for real users with money on the line (i.e., not just hackers) and Windows NT inherits this legacy.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#188

Post by trentnelson »

gpderetta wrote: post #99
Locke1689 wrote: post #85

Earlier quoted context omitted.

NT's approach to async IO is at least somewhat empirically better as it does not require an extra context switch between receiving a "ready" event and actually performing the IO operation.

Completion notification requires committing a (potentially cache-hot) buffer for an operation that might not complete until some time in the future. With readiness notification you only need to have the buffer ready when you know you will use it. Also, on an high performance poll/epoll/kevent based system you only need to poll cold fds, while you can do speculative direct read/writes to hot fds, so no need for extra…

You could do that if you really wanted on Windows; just set a 0 byte user space send and receive socket buffer.

You can do dual synchronous/asynchronous socket I/O in Windows. I use this very approach with PyParallel (and 0 byte send buffers): https://github.com/pyparallel/pyparallel/blob/branches/3.3-p...

Depending on current load, that will either immediately do an asynchronous operation, or attempt synchronous non-blocking ones up to a certain number, then fall back to asynchronous.

Described here: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#189

Post by trentnelson »

zxcvcxz wrote: post #163
trentnelson wrote: post #134

Earlier quoted context omitted.

See here: https://www.reddit.com/r/programming/comments/3jhv80/pyparal... Source: https://github.com/tpn/pyparallel-tefb Go-specific comment thread: https://www.reddit.com/r/programming/comments/3jhv80/pyparal...

I don't see where you take advantage of go routines and I don't see a real world use case unless it's operating on concurrent connections. https://www.reddit.com/r/programming/comments/3jhv80/pyparal... heh..

Patches welcome?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#190

Post by bitwize »

recursive wrote: post #82
zxcvcxz wrote: post #51

Earlier quoted context omitted.

>the NT kernel is much more sophisticated and powerful than Linux Source? It's not sophisticated enough or powerful enough to be the most used kernel on super computers (and in the world). Windows pretty much only dominates the desktop market. Servers, super computers, mainframes, etc, mostly use Linux. A few years ago there was even a bug in Windows that caused degradation in network performance during multimedia pl…

If you're arguing in favor of linux, you probably shouldn't use any arguments that deal with getting audio setups right.

Indeed.

I would go so far as to say that a large part of why audio is such a CF under Linux is -- wait for it -- lack of real asynchronous I/O.

Audio is asynchronous by nature, and to do that right under Linux you need a "sound server" with all the additional overhead, jank, and shuffling of data between kernel and at least two different user spaces that implies. Audio under Linux was best with OSS, which was synchronous in nature and not suitable for professional applications. JACK mitigated that somewhat, but for an OS to do audio right you need a kernel-level async audio API like Core Audio or whatever Windows is doing these days.

Post reply on HN