While studying how concurrency is done in Ada is certainly instructive and even today many languages and multi-threading libraries have more poor support for concurrent programming than Ada had since the beginning, a language that was really ahead of its time regarding concurrency was IBM PL/I.

15 years before Ada, in 1964, IBM PL/I had facilities for multitasking that e.g. included a wait function that could do everything that can be done with WaitForMultipleObjects / WaitForSingleObject. The POSIX threads suck because they lack such a powerful wait function and many other multi-threading libraries, e.g. the C++ standard library, are forced to offer only what is available everywhere, so they do not have anything that is missing in the POSIX threads.

Any kernel based wmo is bot going to work well for fastpathed primitives. For example on windows you can't wmo for critical sections or keyed events.

But you can implement an pure userspace or hibrid user/kernel wmo even on top of something like unix poll just fine, so saying that the standard lacks it because of POSIX is wrong.

The UNIX wait system call, introduced in 1970 or 1971, after porting UNIX to PDP-11, provided a subset of the features of PL/I wait, e.g. it allowed waiting until any of the children of a process terminates.

So UNIX had very early some kinds of waiting for multiple events. A decade later, various other waiting functions, e.g. select and poll were introduced, for networking.

I did not say anything about UNIX processes, but about the standard POSIX threads, the normal way to use multiple threads in a single process under UNIX-compatible operating systems. For example, with pthreads, you can join only a single thread. You can join all threads in an inefficient way, joining them one-by-one, but there is no way to join the first thread that happens to terminate, which is actually the most frequent thing that you want to do.

You can achieve this in a convoluted and inefficient way, using various forms of communication between threads, but this is a very basic feature that should have existed in the standard.

Taking into account that various methods of waiting for multiple events had existed for decades in UNIX, it is even more baffling that this was omitted in the POSIX threads standard. Like I have said, this has also constrained the later standards, e.g. the C++ standard.

Wait doesn’t wait on multiple objects. It just check the process table to see if any children have exited. If they haven’t it waits for a signal... any signal! It also sets a handler for sigchild. Unix in general can’t do the same for and arbitrary object because a) it requires that the waitable only signal a single thing, and b) there are only a small number of signals! So wait is a little special. Generally wait on multiple objects requires a general system to handle asynchronous ipc, which Unix doesn’t have (unlike say windows).

Also if you want to wait on multiple events, use a semaphore!