I thought signals and threads were an iffy combination? Meaning that the main thread tends to intercept all signals? So what if you wanted 2 or 3 buffers? A shared variable can be buffer specific, whereas a signal may be non-specific. (I may have mistakenly used the word "signal" in my node above, in a generic manner, where I really meant "set a shared variable which would signal......."
| [reply] |
They aren't signals in that sense of the word. In the sense of cond_signal().
Basically, the thread in waiting on cond_wait() will not be allocated any timeslices by the scheduler until the other thread calls cond_signal() (or broadcast). So, no polling a second shared var to see if the first is ready yet.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
I'll have to look into that, but if the thread waits (without any timeslices) for the cond_signal from the other thread, that would limit it to watching only 1 thread. The way I envisioned it, the controlling thread could ask many other threads to fill their buffers simultaneously, and then go into a loop to harvest them as they come in, and still do other things as well, like asking for more buffer-filling.
| [reply] |