summaryrefslogtreecommitdiff
path: root/indra/llmessage/llxfer_file.h
diff options
context:
space:
mode:
authorNicky <sl.nicky.ml@googlemail.com>2019-06-07 11:11:56 +0200
committerNat Goodspeed <nat@lindenlab.com>2020-03-25 18:44:04 -0400
commita27281591da9d4023d78f06823adaf2a7d51f724 (patch)
treef1a21b341449192b86ead74309f98e82ec89e136 /indra/llmessage/llxfer_file.h
parent32f1dfa531062071ccf090b9c3d391b274caf02b (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