Maybe not the fault of Microsoft?
I guess if it's an event loop thing one could also alternate 'z' and 'x' as fast as possible :-)
My "first love" in OS's is AmigaOS, and while the OS is very dated in many ways (no memory protection, no SMP support), one of the things it really got right was to encourage extremely extensive multithreading. On Amiga's it was a necessity if you wanted to have full multitasking, as the machines were slow enough and memory constrained enough that not doing it would severely limit usability (frankly, it would have done PC's a world of good too, but the PC world took the simpler approach of not even trying for proper multi-tasking).
My favourite example is how cut and paste from the console worked.
It includes the device handlers handling keyboard and mouse input, the intuition input handler, which processes the raw input events and turns them into input events for specific windows, the console.device device handler which takes intuition events for console windows and "cooks" the events into higher level events that gets passed to the console-handler, which then will find the area you are selecting, and call a function that passes the buffer to the clipboard.device, which will then create a clipboard entry that gets written to a disk volume, which involves the filesystem handler for that filesystem, which again likely will involve a device suck as ram.device or trackdisk.device to write it to the actual device.
Every single one of these steps is handled by a separate thread/process (the distinction doesn't mean much on AmigaOS due to the lack of memory protection, and are usually referred to as "task" instead).
The reason for this is all down to responsiveness: The input devices and things like trackdisk.device musc deal with hardware, and so must have priority. But if the rest of the flow was given high priority, the system would be sluggish, so the minimum amount of work is done, put into a message, tacked onto a queue, and things are off to a start.
At the opposite end, things like clipboard.device must not lock up when clipboard entries are added, as while the clipboards are usually in RAM:, they are files on a filesystem, and a user with only 512KB RAM and possibly no harddrive might in fact be using a floppy drive for the clipboard - forcing the user to wait for a floppy write would have been intolerable (and why Amiga users loved to mock Windows 3.x users back in the day).
This permeated through many applications as well. It was a matter of pride for many developers, and the first chapters in many Amiga developer books tended to involve Exec (Amiga's "kernel", or parts of it) which provided a set of library functions for managing messages, lists of messages and message ports, as they were essential for talking to the OS, but also readily available for application developers. For many, before you'd written your first "hello world" app you had gotten a crash course in making things asynchronous by default.
Today a day go by for me without either my browser freezing, or Thunderbird freezing or some other application, both on Linux at home and OS X at work. And on the few occasions I've had to work on Windows machines, there too. Every time it happens, I dream wistfully about a world where people understood how to write software that way.
It is, in fact, not all that hard: "All it takes" is to subdivide your application into smaller components that only communicate using async message queues. Incidentally it makes the apps easier to test too, and easier to make robust (unlike under AmigaOS, on a modern OS you can separate components on process boundaries where it makes sense too, and automatically restart failed components), and it makes it easy to make them scriptable etc.
Ah, the MS OS/2 2.0 fiasco. I wrote before about http://www.groklaw.net/pdf/iowa/www.iowaconsumercase.org/011... and how it ignores the limitations of the 32-bit Windows extenders, including the lack of preemptive multitasking.
Historically, it was even worse: all desk accessories on Mac OS where running as load able drivers (http://www.folklore.org/StoryView.py?story=Desk_Ornaments.tx.... Aside: that article shows that Jobs did actually design a GUI, that for the calculator. More info at http://www.folklore.org/StoryView.py?project=Macintosh&story...)
I think windows wasn't much different. There is/was an article about the mess that Microsoft's build system for Windows was that explains how they spent lots of effort fixing layer violations in order to improve build times (they used to have full builds only novice every few months. That meant that incompatibilities between, say, an improved menu system and the latest version of the Explorer would take months to surface). Anybody remember that?
Anytime they start indexing or re-indexing a huge code base in a "background" thread, they end up locking the machine to varying extents. Linux is not as bad, as it only tends to lock up instances of the offending application... But that maybe because the Linux PC is a beefy workstation. OS X is on a much less powerful MacBook Pro, and freezes tend to lock up the whole system, or at least most of the other apps, especially Chrome.
I've also had problems with Chrome, and especially Flash, on OS X. Spinning beachballs on every page load. Click-to-flash was such a lifesaver, but I can now sorta see why Steve Jobs wanted Flash dead.
The spinning beachball has grown to be a frequent source of rage for me over the last 5 years. I'm surprised nobody else complains about it more. Maybe it only happens for heavy Java GUI-based apps?
IntelliJ IDEA should run such background threads with lower priority! All common OS support that, and also Java supports this: http://stackoverflow.com/questions/1617963/setting-priority-...
Can someone file a bug for it?
The only Java app I use is BucketExplorer though, which isn't very heavy.
X11 is supposed to be multithreaded enough to allow this and it worked fine on older versions of Xlib, before the libxcb transition.
Fixed by using select() in the event loop for the curious: https://github.com/lcrs/6ilk/commit/d5c39abde09e0467a8a4d17d...
This isn't too uncommon, actually, but what usually happens is that the company with the upper hand prevails and the other one has to fix the bugs, lest they piss off their customers who have to leave. However, when both companies keep their users in tight vendor lockdowns, they just wave their cocks around for a few months blaming each other and settle for the users working around, since it's the cheapest alternative.
Never mind that my callback violated the caller's threading model and that mutices introduce deadlocks when used incorrectly... They should fix the bug!
Edit: I guess what I was trying to say is that this part needs a huge "citation needed":
> was almost certainly built ... according to Microsoft guidelines
We don't know that at all. When you insert your code into another process, bugs in your code have the potential to destabilize that process. This discussion is extremely light on details but we cannot assume that the caller, rather than the callee, is at fault. If it's working correctly with another driver, I say, look at the suspicious driver, it's likely got a bug.
You're right that this discussion is light on details, but there is one relevant detail from which reasonable conclusions can be drawn: there is a workaround that involves moving the mouse around continuously. I can't think of any plausible scenario that could produce that behavior that does not involve some blatantly horrible design decision by Microsoft (hence "their fault"). It's possible that such a scenario exists, but I can't think of one, and I have not seen any such plausible scenario proposed by anyone else. I also know that Microsoft products are chock-full of blatantly horrible design decisions. In particular, Windows tightly couples the graphical UI with the OS kernel in a way that other OSes do not. It seems to me exceedingly likely that whatever is causing this problem has something to do with that.
I suggest it might be helpful to learn how the system works before you bash it.
> If you violate the run loop's threading requirements it's not totally inconceivable that a mouse event could affect behavior.
That's true. But the possibility remains that the design of Windows message queues is so byzantine and imposes so many arcane requirements on the developer that it is easy to miss something. In which case the question of fault is still arguable even if the immediate bug is in Oracle's code. I have a very hard time imagining any circumstances under which an OS could allow a mouse event to impact a database driver -- even if the database driver is buggy -- and still be considered well (or even reasonably) designed. But I'm certainly open to the possibility that I've overlooked something.
No, I didn't overlook this. But this is 2013. IMO, a multitasking architecture that is "sensitive to non-cooperative code" ought to be considered broken, and so if that's the cause of this problem, that still counts as Microsoft's fault in my book.
Is that really the kind of discussion you want this to be?
> you're talking about a problem from 1997,
The last revision of the article is 2002. But your point is well taken. I had assumed this was a current issue. (Maybe it is. I don't have time to dig into those details right now.)
> in an OS where backwards compatibility has been an extremely high priority since the 1980s
OS X was introduced in 2001, and it could run OS 9 applications, so these kinds of problems can be solved if a company decides it is worthwhile to solve them.
Yes. If you're going to chastise people based on what year it is, you damn well better be right about what year it is.
> OS X was introduced in 2001, and it could run OS 9 applications
OS X booted a modified copy of OS 9 to accomplish that. It didn't fix anything about OS 9. It also wasn't present on Intel Macs, nor on Leopard, the last PowerPC-compatible version of OS X. Nor was it fully compatible -- I always had trouble with it, and have kept older System 7 and OS 9 Macs around rather than put up with it.
Kidding aside, I can't help but think that you keep going back to that "clearly the mutex is broken" analogy I mentioned earlier. If I read you correctly, it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation, Microsoft should account for all possible bugs past, present and future and prevent them. Seems like that's asking a lot. The other platforms I've worked with don't seem to satisfy this either.
What bothers me more, though, is how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works. I don't think Win32 is perfect. (Ask me about filesystem behaviors some time.) At the same time I have gotten to know it and can appreciate areas where it works well. I would also hope that before making the kinds of comments you are making about any platform, I'd get to know the framework a bit better first.
I might not be able to show you such a toolkit, but I can certainly show you an operating system that allows you to write a database driver whose behavior is not affected by the user moving the mouse.
> it doesn't matter if the Oracle code is breaking the rules set out by the MS documentation
Of course it matters. I just couldn't imagine what rule there could possibly be that is both 1) broken by a database driver and 2) reasonable, that could possibly result in said driver displaying the behavior in question. (I can imagine such a rule now because to3m pointed out a reasonable possibility in another branch of this thread.)
> how preemptively dismissive you've been about Win32 while showing something of a lack of knowledge on how it works
I freely confess to being (at least potentially) prejudiced against Microsoft's technology by my anger at the fact that they reached market dominance by breaking the law. As a result of that prejudice, I have maintained a carefully cultivated ignorance of all things Microsoft -- until recently. In the past weeks I have found myself in a position where I had to do some Windows development for the first time in my career. So I am far from an expert, but I do now speak from firsthand experience when I say that, in my humble opinion, Windows is every bit the horrible monstrosity on the inside as it has always appeared to me to be on the outside. And, BTW, my opinion is shared by colleagues who know a lot more about it than I do. So yes, my opinion on this is not as well informed as it might or should be, but I have not reached in a total vacuum either.
(The Windows message queue is actually fairly straightforward, and if you read the documentation then it's simpler still. The somewhat magical WM_PAINT message is a bit ugly, but aside from that it's actually quite difficult to get things massively wrong. Which is probably why this sort of freakish bug is rather rare.)
if(dataAvailable())
fetchData();
It's not clear to me, but maybe you know something I don't. What is it exactly that makes this clear? And what is the "way" in which the message pump is being used that makes it break in a GUI app?