On Tue, 11 Jul 2017 15:30:40 -0700, emmil...@gmail.com wrote: > I'm using the new scheduler behavior described here: > > https://github.com/rakudo/rakudo/pull/1004 > > After an "await" on a managed (non-main) thread it appears that > execution > may continue on a different thread than it began on; however, $*THREAD > continues to report the same ID, so that multiple concurrent threads > are > reporting the same thread ID. > > Here's a script that demonstrates the issue 50% of the time. This > starts > three promises, which start work after receiving a message from the > channel. With RAKUDO_MAX_THREADS=2, Promise #1 and #2 will receive the > first 2 messages and start work. Promise #2 has less work and finishes > early. Promise #3 then receives a message from the channel and is > scheduled > on the thread freed by Promise #2. Both Promise #1 and #3 are then > working > concurrently, as demonstrated by CPU usage; however, about half the > time > they report an identical $*THREAD.id. > > Expected behavior: Each thread should report its current, post-await > $*THREAD.id > > Actual behavior: Each thread continues to report its pre-await > $*THREAD.id > Nice find. Dynamic variable lookups in MoarVM are cached, to improve lookup speed. However, the cache was not being invalidated when a continuation was taken (continuations being the mechanism underlying non-blocking `await`), and so an earlier resolution of `$*THREAD` was being re-used after the `await`. Fixed by invalidating the cache (which could conveniently and cheaply be done while walking the call stack to locate the continuation tag). Test added to the Rakudo test suite (t/02-rakudo/09-thread-id-after-await.t), since that allowed for a concise and more reliable test.
/jnthn
