How the Windows Subsystem for Linux Redirects Syscalls • Hacker News Board

Re: How the Windows Subsystem for Linux Redirects Syscalls

#271

Post by binarycrusader » Fri, Jun 10, 2016, 1:03 AM UTC

trentnelson wrote: post #151

binarycrusader wrote: post #135

Earlier quoted context omitted.

Solaris event ports most certainly can be and are used for async I/O. I'm not sure how you can claim otherwise: https://blogs.oracle.com/dap/entry/libevent_and_solaris_even... https://blogs.oracle.com/praks/entry/file_events_notificatio... And Solaris, (unlike Linux historically at least), supports async I/O on both files and sockets. Linux (historically) only supported it for sockets. I have no idea if Linux general…

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…

Your rephrasing still doesn't matter, Solaris event ports are not signal-based.

My understanding is that Solaris event ports were intended to offer equivalent functionality to Windows' I/O completion ports, so this should not be surprising.

Solaris also has its own native async I/O API in addition to supporting POSIX async.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#272

Post by cbd1984 » Fri, Jun 10, 2016, 1:31 AM UTC

tacos wrote: post #196

cbd1984 wrote: post #137

Earlier quoted context omitted.

It works fine as in "I can listen to audio on my laptop from multiple programs at once, with a centralized way to control audio volume on a per-application or per-sound-device basis." I literally cannot imagine any audio system doing better than that given the hardware I have to work with.

https://en.wikipedia.org/wiki/BeOS

BeOS doesn't run on my hardware, I'm pretty sure, even though it was ported to x86 eventually.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#273

Post by lmm » Fri, Jun 10, 2016, 9:52 AM UTC

xorblurb wrote: post #256

lmm wrote: post #250

Earlier quoted context omitted.

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.

Most parts of the NT API have never been officially documented, officially supported, stable (in the "won't change" meaning), and the tiny parts that have actually been documented come with caveats that they are susceptible to change. Supporting fork through the NT API forever makes no sense if there are no users anymore. They could continue to do it for no specific reason, just because fork is internally needed by W…

MS has historically maintained compatibility with even undocumented APIs. Of course that could change.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#274

Post by Maarten88 » Fri, Jun 10, 2016, 9:55 AM UTC

stuaxo wrote: post #229

_khhm wrote: post #29

Earlier quoted context omitted.

They've said the initial intent is for developers to use it, not for running servers / etc (which is why they only target Windows 10 client and not Windows Server OSs).

Yup, when I'm developing I need to run pretty much most stuff. I guess, I can install say postgres using the windows native version, but then we are back at square zero.

Installing postgres on lxss still ends in a 'syscall not implemented' error.