This is more than just a quirk. Lets go through the bogons here:
1. Signal system confuses notifications with commands
2. API ties windows to threads
3. System allows you to send WM_DESTROY from one thread to another even though it provides undefined behavior
4. DestroyWindow() can only be called from a particular thread (related to item #2)
5. The API doesn't detect that the window has been destroyed as far as the application is concerned (whatever happens in ForgetWorkerThread() or PostQuitMessage(), the window actually goes away) without a DestroyWindow() call.
OK, so what's the alternative? Automatic locking at OS-level? How can the performance penalty in those many cases where it is not needed be justified? Same goes for your arguments 3, 4 and 5 btw. Why should such low-level functionality impose important design decisions on those who follow the documentation, just to protect the beginners who don't? I much prefer my raw control, thanks - and I'll happily take the few times I shoot myself in the foot with it, err, with it.
Despite its warts and its legacy cruft, the win32 is quite flexible, and easy to understand - at a very basic level, not much studying of under-the-hood stuff required. For an OS-level API, it packs a lot of power into a small set of concepts.
Well it seems that we hit the nesting limit, so I will reply to this post. I'm not including a URL, I'm just signing my name. Please keep in mind that is a guideline.
> Please don't sign comments, especially with your url. They're already signed with your username. If other users want to learn more about you, they can click on it to see your profile.
This is about an OS-layer API, not a windowing toolkit API. Tying the window to a thread at this layer makes it impossible to have a single-threaded UI application. It is inflexible.
"This is about an OS-layer API, not a windowing toolkit API"
What does that even mean? Of course you can have single-threaded UI applications in Windows, the majority of them are. Have you ever written a Windows application in C or C++?
Sorry. I've read your comment a couple of times and am unable to make any sense of it. Win32 is a (dated, clunky) API for writing GUIs (in part). "OS-layer" is babble in this context.
And yeah, i would stop signing your posts - it comes across as conceited somehow; like each comment is a big deal.
Wow, thanks for exposing me to how braindamaged win32 really is.
To be perfectly fair, this arrangement (which I don't like either) is actually inherited from the Windows 3 API (Win16) and very likely goes back all the way to Windows 1.
In North America there seem to be two seasons for apples: autumn in North America, and autumn in South America. In September and October you get the fresh NA apples. In March and April you get the fresh SA apples. There is no reason to have an apple older than 6 months.
Also, this fictional account appears in Wireless, a collection of short stories and novellas by Stross. It is great to see that medium still alive and publishable.
There are two contributions to the load factor: number of processes/threads on the ready-to-run queue and the number blocked on I/O. The processes blocked on I/O show up in the "D" state in ps and top and also contribute to this number.
This article entirely ignores the number of processes blocked on I/O. A load average exceeding the number of CPUs (cores, whatever) does not automatically mean the CPUs are overloaded.
Thank you, finally someone who managed to mention it. I was at some point thinking that I've misunderstood the whole concept of load, but now you just confirmed my initial doubt, they are trying to sell a product.
How did this end up on HN? You have equally good articles on load at Wikipedia.
Not all processes blocked on I/O are in D state - for a common example, processes blocked on I/O to a network socket or terminal will simply be in the S state, and not count towards load.
In practice, processes typically go into D state ("uninterruptible sleep") when they're blocked on access to a local disk, whether that's explicit I/O (read/write) or implicit (paging). Not coincidentally, this is also the one type of blocking I/O that you can't get knocked out of by a signal.
Actually, they'll get blocked on access to NFS or other network-based disk, too. (but you can configure the NFS mount to allow signals to interrupt) I've seen NFS problems lead to loads over 100.
-molo