Hacker News new | ask | show | jobs
by iforgotpassword 1252 days ago
I guess it's because in web context, it's easier to do web calls async than sync. While it's perfectly possible to do async web calls in something like C++, or at least move stuff to a different thread, people just somehow don't. Maybe out of lazyness since the first Google result was sync, or because lifecycle management is harder if raw pointers are involved, or whatever else.
3 comments

I'm guilty of this. Back when I was writing Java apps using Swing, I'd perform heavy blocking IO operations in button event handlers synchronously. Looking back, I realise how much haram I was committing.
It's because the default program structure in C and C++ makes functions blocking, with the caller assuming that if the callee returned it completed. Jamming a non-blocking program structure smack in the middle of a blocking system is never pretty, and most people prefer not to deal with the additional complexity. For the same reason, even though Windows has overlapped IO and other asynchronous IO mechanisms, most people prefer to use the synchronous functions.
For disk IO you usually get away with it, especially now with SSDs. For networking you don't even have to use overlapped IO, sockets can be used with window messages, winhttp can be used async, etc. I think "it's more involved" is a really shitty excuse, especially if we're talking about a Microsoft product, not some obscure shareware software a guy is developing in his shed in the middle of nowhere.
I'm not excusing this particular case, I'm just explaining the perspective of most developers regarding synchronous versus asynchronous operations. In this particular case there's no reason to do it synchronously, since multiple processes are involved anyway. The crash handler should definitely not be waiting on a network operation to let the process terminate (that's not even getting into whether crash dumps should be getting uploaded by default to begin with), and the fact that this is a central part of the operating system's UI is even more egregious.
In some cases I wonder if the Office team had internal coding policies against threading because they aren’t sure about thread safety on some legacy structures. I remember reporting the issues Outlook had blocking UI waiting on network calls in the Office 97 beta (oh, was I an optimistic teenager) and multiple decades later that’s still affecting users.