3 ms·

> when I realized that most mainstream desktop UI applications were fundamentally broken. Oh boy > File system IO functions belong to a class of functions cal

> when I realized that most mainstream desktop UI applications were fundamentally broken. Oh boy > File system IO functions belong to a class of functions called blocking functions. Hasn’t non-blocking IO been a major feature for about a decade now??

deepspace 3y ago
Someone has not told Microsoft | It is not as simple as that. On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive. This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching its worst-case performance. In turn the library writers probably blithely coded something like "check if all mounted drives are accessible", without stopping to consider the worst-case performance.
- pdonis 3y ago
  > Someone has not told Microsoft More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perfectly good asynchronous file I/O API calls.
  - kudokatz 3y ago
    > never bothered to tell the part of Microsoft that writes the generic Windows UI code no, they just don't care.
- pradn 3y ago
  The file picker on Windows should be thought of as more like a process than a function call. It has to 1) read the metadata of the current directory’s files 2) look up which icon to use for each 3) load the icon 3) call apps that may modify the file icon overlay (like “synced” or “not synced” cloud icons for Cloud file systems like Google Drive) 4) read the registry for various settings 5) load which pinned files a user set up - etc etc. All this involves dozens of disk reads, calling into third party code, etc. A lot of this may be cached but who knows. The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.
  - rootw0rm 3y ago
    You're right, Sysinternals Process Monitor will show lots of stuff going on for your example.
anonymoushn 3y ago
> Hasn’t non-blocking IO been a major feature for about a decade now?? This doesn't make people use it, and even the ones that try to use it might erroneously expect that open(2) will return in less than a second.
yetanotherloss 3y ago
More like three decades. But you'll need to send the memo to small time players like Microsoft, who continue doing all kinds of stupid blocking IO on every possible user interaction because who even fucking knows.

deepspace 3y ago

Someone has not told Microsoft | It is not as simple as that. On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive. This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching its worst-case performance. In turn the library writers probably blithely coded something like "check if all mounted drives are accessible", without stopping to consider the worst-case performance.

pdonis 3y ago
> Someone has not told Microsoft More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perfectly good asynchronous file I/O API calls.
- kudokatz 3y ago
  > never bothered to tell the part of Microsoft that writes the generic Windows UI code no, they just don't care.
pradn 3y ago
The file picker on Windows should be thought of as more like a process than a function call. It has to 1) read the metadata of the current directory’s files 2) look up which icon to use for each 3) load the icon 3) call apps that may modify the file icon overlay (like “synced” or “not synced” cloud icons for Cloud file systems like Google Drive) 4) read the registry for various settings 5) load which pinned files a user set up - etc etc. All this involves dozens of disk reads, calling into third party code, etc. A lot of this may be cached but who knows. The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.
- rootw0rm 3y ago
  You're right, Sysinternals Process Monitor will show lots of stuff going on for your example.

anonymoushn 3y ago

> Hasn’t non-blocking IO been a major feature for about a decade now?? This doesn't make people use it, and even the ones that try to use it might erroneously expect that open(2) will return in less than a second.

yetanotherloss 3y ago

More like three decades. But you'll need to send the memo to small time players like Microsoft, who continue doing all kinds of stupid blocking IO on every possible user interaction because who even fucking knows.