[devit]

The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels).

For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux apps instead of giving up.

(your reasoning about the dentry cache makes no sense though since such a cache would be implemented by the NT kernel and certainly not by WSL1, so there's no difference between Linux and Windows programs)

[jcranmer]

> (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels)

That is a coffee-spewing statement. Linux generally has a reputation of approaching new features by coming late to the party, seeing the mistakes everyone else made in the feature, and then implementing it somehow even more poorly than everybody else.

An example of a particularly bad Linux subsystem is ptrace, which interacts poorly with threads, relies on signals (itself a bit of a mess of a feature), and is notorious for all the races you have to do to actually properly set up a debugger. The Windows debugger API is much simpler, and even includes some features I'd love to have in Linux instead (hello, CreateRemoteThread!). I was going to write to the parent comment that implementing ptrace to let you run gdb (or, worse, rr!) in WSL1 would have been something that every NT kernel programmer would have "NOPE"d at because the impedance mismatch is just that high.

[saagarjha]

I mean, it's entirely possible to implement ptrace if you spend enough time doing it, it will just be complicated and the performance will likely be not that great. (But yes, it's a pretty bad API.)

[hapless]

As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible.

Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway.

Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem.

https://github.com/microsoft/WSL/issues/873#issuecomment-424...

https://github.com/microsoft/WSL/issues/873#issuecomment-425...

The second link explains why a dentry cache just isn't feasible.

The short version is that the NT IO APIs seem to have been very, very ill-considered. It's just not possible to make it fast. Even win32 operations are extremely slow, so win32 applications go out of their way to avoid doing any file I/O. Linux applications were not written with those constraints in mind.

[dblohm7]

Amusingly enough, I just watched a talk about this topic earlier today:

https://www.youtube.com/watch?v=qbKGw8MQ0i8

[meddlepal]

> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels

Citation needed.

[tannhaeuser]

> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels

Another interpretation is that Linux has been trying to re-implement Unix for 30 years, when the point of Unix in 1970 was a simple portable operating system that can be coded in like half a year.

[CJefferson]

I find IO on windows is fine, the problem with WSL1 was that the standard windows model doesn't line up well with Linux (fairly fundamental things like in Linux you can delete open files, which you can't do in Windows).

You couldn't switch Windows to a more linux-like model, it would break all existing windows programs.

[cpuguy83]

You can delete open files on Windows, but you need the right option (FILE_SHARE_DELETE).