which languages have a way to wait on 2 or more things at the same time. easily, without doing programming tricks? suppose you want to wait on either event X or event Y, whichever happens next, waking up immediately when it happens. how would this be best coded in the languages that can do this. anything must be waitable, including I/O and timers and messages from other tasks (threads or processes).

for example bash (shells) has the command wait. Is this what you are looking for?

Pretty much, all of them.

If by that you mean without writing code to handle it, pretty much non of them.

Typically you write an event loop and handle whatever occurs. Or, you use a ready made async event framework such as libevent.

1 members found this post helpful.

Or use a language that comes event-driven out-of-the-box.

Might be helpful to understand the purpose for your question.

I agree many, if not all languages have the capability to block on several conditions simultaneously.

The pthread library has a general mechanism: the application program does both the wait and the wake-up on different threads. The conditions can be anything.
Ed

1 members found this post helpful.

Well, yes, multiple threads. There is select/poll for IO, wait(2) for child-processes, XNextEvent for XWindow, semop/sema_wait for semaphores, also pthread_mutex_lock etc

All of them.

Although Node and Go are actually designed around this.

Do be aware that the architecture you seem to be talking about, where you do a blocking read, and the kernel puts the process to sleep until data comes in, would not work if you're reading more than one event source. Instead, you'd use the following:

https://en.wikipedia.org/wiki/Event_loop

Many of the replies in this thread have made suggestions as to how to achieve this.

so, i could have thread 1 just wait for event 1, and thread 2 just wait for event 2. then there is an existing thread call to wait on 2 or more threads? or would i have to have threads 1 and 2 send a message to thread 3?

i hope the waiting syscalls don't block the whole process.

right now my specific waits are a repeating one second tick that does not accumulate offset errors, and the arrival of an ICMP ping reply. this is to detect a lost WIFI route. disconnecting and reconnecting the WIFI fixes it. i want detect the situation as fast as possible. so every second, if the past N seconds has had no received ICMP ping reply, run the reconnect code.

thinking about this in a supposedly portable language i wondered if any language directly supported this in simple uniform code.

Multitasking and Multithreading are not things that you learn on one day and once for all occasions.
While I want to throw in polling as another – often just as useful, sometimes impossible, usually simpler – technique, here is all you must know about Threads in 'C':
https://www.gruble.de/search?q=DAvid...language=en-US

I am not sure, but remember that the importance of Threads is about the same with Linux as that of Tasks with MS® Windows® or vice versa. This may become important, sometimes.., or not.

I love Threads and use them more often nowadays, but the very first time I thought it will be the right thing to do, my boss let me the freedom to punch my head against a wall (did that often) a few times, then told me to consider Polling, instead. He was right, of course.

Theoretically you can implement whatever you want. Either blocking or non-blocking calls (with other words: sync or async calls) ...

You don't need multithreading/multitasking for this:
ping continuously (in every second?) | grep pattern (will detect error condition and stop) && reconnect wifi && restart script/loop.

That is what I called Polling, above. I do not know if it is really a valid convention, but we used to have discussions about Polling versus Multi-T* to achieve the same.

Yes, you are right, it is called polling. https://en.wikipedia.org/wiki/Polling_(computer_science)

The latter. See the documentation for pthread_cond_wait () and pthread_cond_broadcast ().

Waiting syscalls block the thread. Other threads can still run.

Now that you have described the problem, I think that multi-threading is a more powerful solution than you need. You should be able to get by with an event queue or polling as others have suggested.
Ed