What do POSIX and other standards say about the situation where multiple threads are doing poll()
or select()
calls on a single socket or pipe handle at the same time?
If any data arrives, does only one of the waiting threads get woken up or do all of the waiting threads get woken up?
Polling repeatedly checks the status of an asynchronous call from within a loop. Polling is the least efficient way to manage threads because it wastes resources by repeatedly checking the status of the various thread properties. For example, the IsAlive property can be used when polling to see if a thread has exited.
There is nothing wrong in calling same function from different threads. If you want to ensure that your variables are consistent it is advisable to provide thread synchronization mechanisms to prevent crashes, racearound conditions.
In a multithreaded process on a single processor, the processor can switch execution resources between threads, resulting in concurrent execution. Concurrency indicates that more than one thread is making progress, but the threads are not actually running simultaneously.
JavaScript does not support multi-threading as the JavaScript interpreter in the browser is single-threaded. Even our famous Web browser, Google Chrome, will not let a single JavaScript page run concurrently as it could cause issues in the application.
Interesting question ... I read through the current POSIX and did not find a specific answer, i.e., no specification about concurrent invocations. So I'll explain why I think the standard means all will wake up.
The relevant part of the text for select
/ pselect
is:
Upon successful completion, the pselect() or select() function shall modify the objects pointed to by the readfds, writefds, and errorfds arguments to indicate which file descriptors are ready for reading, ready for writing, or have an error condition pending, respectively, [...]
and later
A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.)
In short (the reading case only), we can understand this as:
select
does not block this means that the next call to an input function with O_NONBLOCK
would not return an error with errno==EWOULDBLOCK
. [Note that the "next" is my interpretation of the above.]
If one admits to this interpretation then two concurrent select
calls could both return the same FD as readable. In fact even if they are not concurrent, but a first thread calls select
with some FD being readable and later e.g., read
, a second thread calling select
between the two could return the FD as readable for the second thread.
Now the relevant part for the "waking up" part of the question is this:
If none of the selected descriptors are ready for the requested operation, the pselect() or select() function shall block until at least one of the requested operations becomes ready, until the timeout occurs, or until interrupted by a signal.
Here clearly the above interpretation suggests that concurrently waiting calls will all return.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With