3 ms·

The message queue is user-space abstraction relevant to the GUI subsystem and not something that is inherent to Win32 threading model. And in fact its implicit

by dfox 7y ago

The message queue is user-space abstraction relevant to the GUI subsystem and not something that is inherent to Win32 threading model. And in fact its implicit existence is source of completely unique Win32 class of hard to debug threading bugs. Edit: on the other hand Win32 has one really nice feature: you can WaitForMultipleObjects() on essentially anything that has kernel handle, which includes most of IPC primitives. On the other hand this causes the native Win32 IPC to have significant overhead and is the reason why game developers often resort to userspace spin-locks and why Windows 10 had introduced NPTL/Linux-style lightweight futex-based mutexes...

int_19h 7y ago
Win32 message queues are not only relevant to the GUI subsystem. Note how PostThreadMessage doesn't even deal with HWNDs anywhere. And COM, for example, uses those same message queues for cross-apartment calls - even if it's one GUI-less service calling another one, there's a message pump in there somewhere.
- dfox 7y ago
  I somewhat believe that the sole reason for existence of PostThreadMessage and friends is to make COM cross-apartment calls work for threads that do not own any windows. You can probably devise other uses for that, but such uses still somewhat boil down to implementing your own COM-like bidirectional IPC mechanism (GIMP's libwire comes to mind, which does essentially the same thing on top of “anything that behaves like SOCK_STREAM socket” and shared temporary directory)
badsectoracula 7y ago
It may not be inherent but IMO that is just hair-splitting, the important part is that it is there (also FWIW i had PostThreadMessage in mind, not PostMessage) and is very convenient to use. I've used it a bunch of times whenever i worked on Win32 tools that i wanted threading by sending commands to other threads to do stuff (e.g. enumerating the directory structure for an asset browser in a game editor at the background to avoid stopping the UI) and having them reply back with messages about the results. And honestly i never had any bugs with that, if anything i've found it the easiest approach to understand when it comes to inter-thread communication.

by dfox 7y ago

int_19h 7y ago

Win32 message queues are not only relevant to the GUI subsystem. Note how PostThreadMessage doesn't even deal with HWNDs anywhere. And COM, for example, uses those same message queues for cross-apartment calls - even if it's one GUI-less service calling another one, there's a message pump in there somewhere.

dfox 7y ago
I somewhat believe that the sole reason for existence of PostThreadMessage and friends is to make COM cross-apartment calls work for threads that do not own any windows. You can probably devise other uses for that, but such uses still somewhat boil down to implementing your own COM-like bidirectional IPC mechanism (GIMP's libwire comes to mind, which does essentially the same thing on top of “anything that behaves like SOCK_STREAM socket” and shared temporary directory)

badsectoracula 7y ago

It may not be inherent but IMO that is just hair-splitting, the important part is that it is there (also FWIW i had PostThreadMessage in mind, not PostMessage) and is very convenient to use. I've used it a bunch of times whenever i worked on Win32 tools that i wanted threading by sending commands to other threads to do stuff (e.g. enumerating the directory structure for an asset browser in a game editor at the background to avoid stopping the UI) and having them reply back with messages about the results. And honestly i never had any bugs with that, if anything i've found it the easiest approach to understand when it comes to inter-thread communication.