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

241–250 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#241

Post by trentnelson »

jamespo wrote: post #225
trentnelson wrote: post #168

Earlier quoted context omitted.

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_execut…

I always thought the external table functionality was a terrible idea, but if the use case is just for import that's more reasonable. Don't you like SQL*Loader or something ;)

It's great when you need to whip something up quickly. My workflow was to create foo_ext, poke around at the data and get some sensible column defaults, then `create table foo select * from foo_ext`. Worked really well, especially for once-off or infrequent stuff.

For batch-oriented stuff where you're getting pretty consistent data at a regular interview I'd go with SQL*Loader.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#242

Post by trentnelson »

makomk wrote: post #237
bitwize wrote: post #182

Earlier quoted context omitted.

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…

It's only the right way to do it from an application developer's perspective if the behaviour of the official OS-approved interface matches what their application needs, which is unlikely to be the case here. For example, according to https://support.microsoft.com/en-us/kb/156932 there's a fixed-sized pool of threads used to fetch data into cache to fill async I/O requests. If you try to have too many async I/O reque…

> (Also, curiously when the data's in the cache that page shows a performance penalty for async reads that complete synchronously from the cache compared to sync reads. Wonder why.)

Because a synchronous operation is always faster than an overlapped operation if it can be completed synchronously.

Lots of stuff happens behind the scenes when an overlapped operation occurs.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#243

Post by trentnelson »

akavel wrote: post #214
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…

Curious if you've ventured into (good/modern? maybe QNX?) microkernels at some point and have some thoughts on them by chance?

I have not I'm afraid. Hard enough keeping how all the parts of NT work in my head at the same time ;-)

Re: How the Windows Subsystem for Linux Redirects Syscalls

#244

Post by ambrop7 »

geocar wrote: post #238
ambrop7 wrote: post #236

Earlier quoted context omitted.

> something might poll and not-block, but actually block by the time you get around to using the buffer On Linux if a socket is set to non-blocking it will not block. I don't really understand your point with shared buffers. You wouldn't typically share a TCP socket since that would result in unpredictable splitting/joining of data. > In Linux, you don't, and userspace and kernelspace both end up doing unnecessary co…

> I'm not so sure the Linux design where copies are done in syscalls must be inherently less efficient. Windows overlapped IO can map the user buffer directly to the network hardware, which means that in some situations there will be zero copies on outbound traffic. > especially the RX copy I also don't think you need more than one copy, if you design the network stack with that in mind. When the interrupt occurs, th…

Thanks for the info. Yes I suppose zero-copy can be made to work but surely one needs to go through a LOT of trouble to make it work.

I'm curious about sending data for TCP through, don't you need to have the original data available anyway, in case it needs to be retransmitted? Do the overlapped TX operations (on Windows) complete only once the the data has also been acked? Are you expected to do multiple overlapped operations concurrently to prevent bad performance due to waiting for ack of pending data?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#245

Post by trentnelson »

4ad wrote: post #234
trentnelson wrote: post #115

Earlier quoted context omitted.

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…

> Write a kernel driver on Linux and NT and you'll see how much more superior the NT I/O subsystem is. I wrote Windows drivers and file systems for about 10 years, and Unix drivers and file systems also for about 10 years. I'd rather practice substance agriculture for the rest of my life than deal with Windows drivers again.

Yeah it's not a simple affair at all. It's a lot easier these days though, and the static verifier stuff is very good.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#246

Post by vegabook »

mxuribe wrote: post #162
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…

I've been heavily downvoted for the view, but the facts are, there are hundreds of billions of dollars being spent in the Linux ecosystem, by corporations. Microsoft cannot afford not to be present in it. It's as simple as that. Canonical is starting to look like hitting Red Hat a bit on support contracts for corpos ets, so that's why I suggested that, but as you say, it could be another big and credible Linux distro (though Ubuntu all over the cloud must surely be tempting). Generally the idea that Microsoft wants to/must go big into Linux is uncontroversial, for me.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#247

Post by jdmichal »

wtallis wrote: post #64
jdmichal wrote: post #53

Earlier quoted context omitted.

I'm not familiar with what you mean by readline compatibility. I see a GNU Readline library with history functions, but I'm not sure what that means being integrated into a shell, and what features you would expect to see. My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you des…

Powershell's completion is worthless for the most common use case of saving keystrokes . Since it fills in the entire remaining command name and cycles through the possibilities in alphabetical order instead of completing just what's unambiguous and presenting a list of the possibilities from there, it doesn't help with typing out common prefixes and if you find yourself cycling through an unreasonably large number o…

See, and I personally dislike the system you mention. It bugs me to no end to have only a couple options, but the system will only fill in the common prefix. Now I have to look, figure out what's there already, figure out what the next letter is, hit it, then hit tab again. If I want to save key strokes, that what aliases and symlinks are for, not tab completion.

Also, at least in PowerShell 5, if you run the ISE instead of the cmd-based terminal, it shows an IDE-like overlay of completions while you're typing.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#248

Post by ygra »

jdmichal wrote: post #247
wtallis wrote: post #64

Earlier quoted context omitted.

Powershell's completion is worthless for the most common use case of saving keystrokes . Since it fills in the entire remaining command name and cycles through the possibilities in alphabetical order instead of completing just what's unambiguous and presenting a list of the possibilities from there, it doesn't help with typing out common prefixes and if you find yourself cycling through an unreasonably large number o…

See, and I personally dislike the system you mention. It bugs me to no end to have only a couple options, but the system will only fill in the common prefix. Now I have to look, figure out what's there already, figure out what the next letter is, hit it, then hit tab again. If I want to save key strokes, that what aliases and symlinks are for, not tab completion. Also, at least in PowerShell 5, if you run the ISE ins…

> if you run the ISE instead of the cmd-based terminal

PowerShell depends (or is based) in no way on cmd.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#249

Post by geofft »

stuaxo wrote: post #235
geofft wrote: post #30

Earlier quoted context omitted.

"As Brother Francis readily admitted, his mastery of pre-Deluge English was far from masterful yet. The way nouns could sometimes modify other nouns in that tongue had always been one of his weak points. In Latin, as in most simple dialects of the region, a construction like servus puer meant about the same thing as puer servus , and even in English slave boy meant boy slave . But there the similarity ended. He had f…

What is this from ?

Walter Miller's A Canticle for Leibowitz.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#250

Post by lmm »

xorblurb wrote: post #95
pcwalton wrote: post #89

Earlier quoted context omitted.

> So even if there was an NT API fork syscall You can do it with NtCreateProcess: https://groups.google.com/d/msg/microsoft.public.win32.progr... (The Win32 userland won't understand what you did, but you can still do it.)

Well, you can do it on some versions of Windows. On Windows 10, and even future version of Windows 10, not so sure...

Windows 10 is still windows NT. The NT native API is widely used these days. It would be a huge departure for MS to stop supporting it in future versions of windows.
Post reply on HN