diff options
author | Nicky <sl.nicky.ml@googlemail.com> | 2019-06-07 11:11:56 +0200 |
---|---|---|
committer | Nat Goodspeed <nat@lindenlab.com> | 2020-03-25 18:44:04 -0400 |
commit | a27281591da9d4023d78f06823adaf2a7d51f724 (patch) | |
tree | f1a21b341449192b86ead74309f98e82ec89e136 /indra/llmessage/llxfer_file.h | |
parent | 32f1dfa531062071ccf090b9c3d391b274caf02b (diff) |
Replace boost::fibers::unbuffered_channel with boost::fibers::buffered_channel.
Using boost::fibers::unbuffered_channel can block the mainthread when calling mPendingCoprocs.push (LLCoprocedurePool::enqueueCoprocedure)
From the documentation:
- If a fiber attempts to send a value through an unbuffered channel and no fiber is waiting to receive the value, the channel will block the sending fiber.
This can happen if LLCoprocedurePool::coprocedureInvokerCoro is running a coroutine and this coroutine calls yield, resuming the viewers main loop. If inside
the main loop someone calls LLCoprocedurePool::enqueueCoprocedure now push will block, as there's no one waiting for a result right now.
The wait would be in LLCoprocedurePool::coprocedureInvokerCoro at the start of the while loop, but we have not reached that yet again as LLCoprocedurePool::coprocedureInvokerCoro
did yield before reaching pop_wait_for.
The result is a deadlock.
boost::fibers::buffered_channel will not block as long as there's space in the channel. A size of 4096 (DEFAULT_QUEUE_SIZE) should be plenty enough for this.
Diffstat (limited to 'indra/llmessage/llxfer_file.h')
0 files changed, 0 insertions, 0 deletions