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

161–170 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#161

Post by haberman »

trentnelson wrote: post #115
piscisaureus wrote: post #104

Earlier quoted context omitted.

I wrote the windows bits for libuv (node.js' async i/o library), so I have extensive experience with asynchronous I/O on Windows, and my experience doesn't back up parent's statement. Yes, it's true that many APIs would theoretically allow kernel-level asynchronous I/O, but in practice the story is not so rosy. * Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented…

You're completely missing how the NT I/O subsystem works, and how to use it optimally. > * Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented ( https://support.microsoft.com/en-us/kb/156932 ), but asychronous I/O also actually blocks in cases that are not listed in that article (unless the disk cache is disabled). This is the reason that node.js always uses thread…

> The key to NT asynchronous I/O is understanding that the cache manager, memory manager and file system drivers all work in harmony to allow a ReadFile() request to either immediately return the data if it is available in the cache, and if not, indicate to the caller that an overlapped operation has been started.

The Microsoft article cited above (https://support.microsoft.com/en-us/kb/156932) directly contradicts you:

> Be careful when coding for asynchronous I/O because the system reserves the right to make an operation synchronous if it needs to. Therefore, it is best if you write the program to correctly handle an I/O operation that may be completed either synchronously or asynchronously.

Microsoft is directly saying that it reserves the right to violate the guarantee you are counting on at any time, and it documents several known cases of this. You can try to guess when this will happen and put those I/O operations on a different thread pool, but you're just playing whack-a-mole. And you're violating Microsoft's own recommendations.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#162

Post by mxuribe »

vegabook wrote: post #58

Next step is Microsoft basically needs to turn Windows into a flavour of Linux. If they don't, they're under massive pincer threat from Android and Chrome, which are rapidly becoming the consumer endpoints of the future. Windows is about to "do an IBM" and throw away a market that it created. See PS/2 and OS/2. They should probably just buy Canonical. That would put the shivers into Google, properly.

Funny years ago i would have reflexively flabbergasted at the thought of microsoft buying canonical (or any linux distro producer)...but actually thinking on that concept, and seeing recent (perhaps less-than-hostile) approach that microsoft has taken towards open source and linux, that wouldn't be a bad idea. I mean if microsoft could have both offerings - for windows servers and ubuntu-installed servers - i suppose that would be a very smart business move. Assuming they don't actually butcher or deny resources to whatever linux company they would buy, i could see several benefits - not only to microsoft but to developers, system integrators, etc. worldwide. Hey if a side benefit is that it would spur the market (a la google, apple, etc.) a little - to the benefit of us civilians - that's cool too.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#163

Post by zxcvcxz »

trentnelson wrote: post #134
zxcvcxz wrote: post #105

Earlier quoted context omitted.

http://pyparallel.org/wrk-rps-comparison2.svg According to your website pretty much every other technology runs better on Linux than it does on Windows, and of course pyparallel runs better than everything you tested. How can I run these tests my self? I specifically want to test it against golang.

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

Re: How the Windows Subsystem for Linux Redirects Syscalls

#164

Post by zxcvcxz »

trentnelson wrote: post #139
e12e wrote: post #126

Earlier quoted context omitted.

Now I'm curious; have you played with reactOS at all? Do they implement the same VMS paradigm? That is, if given decent hw drivers for io on ReactOS, could one expect performance on the same order of magnitude as with a new nt-derived kernel?

I haven't actually. Although now I'm kind of curious.

Why did you two have this same conversation 383 days ago?

https://news.ycombinator.com/item?id=9584269

Re: How the Windows Subsystem for Linux Redirects Syscalls

#165

Post by stordoff »

l3m0ndr0p wrote: post #16
serge2k wrote: post #10

Earlier quoted context omitted.

> Get rid of the Windows NT Kernel. I believe it's outdated & doesn't have the same update cycle that the Linux Kernel has. Curious why you claim this? What's outdated about the NT Kernel?

Here are some, or maybe this is not part of the NT Kernel... 1. The use of drive letters A-Z for file system access. 2. Creating symbolic links to files and folders, like you can in Unix/Linux. You have to set a setting somewhere to enable this, but there's a security risk. 3. Standard functional/usable non-gui terminal application like Unix/Linux ssh. PowerShell doesn't come close. 4. Ability to SUDO or su Admin lik…

> 1. The use of drive letters A-Z for file system access.

Why is this a problem? As a user, I've always preferred to have drive letters - it makes it immediately clear if, for example, I'm moving files between different physical drives.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#166

Post by adamnemecek »

trentnelson wrote: post #157
adamnemecek wrote: post #141

Earlier quoted context omitted.

Can I ask what else is on your reading list? I ended up buying the VMS Internals book. Also do you have an opinion on BeOS?

I was fascinated by BeOS in the late 90s when I had a lot of enthusiasm (and little clue). All their threading claims just sounded so cool. I was also really into FreeBSD from around 2.2.5 so I got to see how all the SMPng stuff (and kqueue!) evolved, as well as all the different threading models people in UNIX land were trying (1:1, 1:m, m:n). NT solves it properly. Efficient multithreading support and I/O (especial…

Lol, I've been saying something like this for some time.

Thanks for the answer. I guess what I'm interested is somewhat obscure/historical operating systems and also HW that are in some way superior to currently popular solutions. The more comparative the better.

Also your reading list has quite a few Oracle SQL entries so I'm guessing it's your preferred DB of choice. What features are you using that aren't available in MySQL or Postgres?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#167

Post by supernovae »

clevernickname wrote: post #123
zxcvcxz wrote: post #114

Earlier quoted context omitted.

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not…

The simplest explanation is that the performance benefit of using Windows and implementing just about any Windows-specific design is outweighed by the cost of the Windows licensing fees, when compared to a measurably worse-performing Linux or FreeBSD solution that costs nothing. So very few bother to treat Windows versions of "backend" software as anything but an afterthought.

Not really... the license model provides support and creates fairly standard releases by which you can more easily leverage. If licensing or selling software is your thing. If all you need is something good enough and cheap then licensing could get in the way

Re: How the Windows Subsystem for Linux Redirects Syscalls

#168

Post by trentnelson »

adamnemecek wrote: post #166
trentnelson wrote: post #157

Earlier quoted context omitted.

I was fascinated by BeOS in the late 90s when I had a lot of enthusiasm (and little clue). All their threading claims just sounded so cool. I was also really into FreeBSD from around 2.2.5 so I got to see how all the SMPng stuff (and kqueue!) evolved, as well as all the different threading models people in UNIX land were trying (1:1, 1:m, m:n). NT solves it properly. Efficient multithreading support and I/O (especial…

Lol, I've been saying something like this for some time. Thanks for the answer. I guess what I'm interested is somewhat obscure/historical operating systems and also HW that are in some way superior to currently popular solutions. The more comparative the better. Also your reading list has quite a few Oracle SQL entries so I'm guessing it's your preferred DB of choice. What features are you using that aren't availabl…

As far as commercial vendors go I really preferred SQL Server from about version 2000 onwards. I got into Oracle again recently for a consulting project with a finance client (who basically have unlimited Oracle licenses) and really quite enjoyed it since the Oracle 7/8 days.

You can do some phenomenally sophisticated things... I extensively leveraged things like partitioning, parallel execution (dbms_parallel_execute!), lots of PL/SQL using the pipelined table cursor stuff, data mining stuff (dbms_frequent_itemset!), index-organized tables, and my god, bitmap indexes were a godsend, direct insert tricks for bulk data loading, external tables were fantastic (you can wrap a .csv in an external table and interact with it in parallel just like any other table -- great for ingesting large amounts of janky .csv data from other parts of the business).

The parallel execution and robust partitioning options were probably the most critical pieces that have no particularly good counterpart in open source land.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#169

Post by [deleted] »

xorblurb wrote: post #71
bitwize wrote: post #47

Earlier quoted context omitted.

When it comes to system call interfaces, it's because Dave Cutler has forgotten more than many modern "kernel hackers" will ever know about how to design an OS.

Well, that's an (unbacked) opinion, and I don't share it. NT design is not too bad (obviously especially in contrast with Consumer Windows), and especially given what was achieved on the first few releases (that was made easier by Cutler serious experience in the area), but now it is far from brillant, and it has it (huge) share of problems every serious users of both Windows and Unix based OS knows. Now at one point…

[deleted]

Re: How the Windows Subsystem for Linux Redirects Syscalls

#170

Post by politician »

zxcvcxz wrote: post #114
Koromix wrote: post #111

Earlier quoted context omitted.

I only have superficial experience with it, but from what I can tell there is a huge mismatch between IOCP and the UNIX readiness/poll model, and from my experience most server programs are written primarily for the latter. You need to design your server code somewhat differently to take advantage of IOCP. What many UNIX-like softwares do instead is bend IOCP or WaitForMultipleObjects() to behave like Linux. It works…

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not…

IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping. However, it's hard to grok because it's a very different model, most servers are proprietary code, and the MSDN documentation is barely sufficient (at least, back when I was writing IOCP-based servers in '09).
Post reply on HN