Use separate io_manager when spawn engine #28220
Conversation
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
zsunkun
force-pushed
the
use_separate_io_manager_sunkun
branch
from
465051b to
100797d
Compare
|
@gaaclargar @blasten @iskakaushis A PR of my teammate, please take a review~ thanks |
gaaclarke
left a comment
gaaclarke
left a comment
There was a problem hiding this comment.
Hi zsunkun, good detective work. This PR is going to need tests. I recommend writing tests that recreate the crash (without your change).
|
Agreed, the test to add would go in the |
|
Any updates? |
|
Closing this as stale. Please re-open once this is good for another review. Thanks. |
|
This PR takes place of it #29915 |
4 participants
Each Engine should use its own io_manager when spawn new engine. The current situation is that when a new Engine is spawned from an old Engine, the new Engine will use the io_manager of the old Engine. the new Engine will be crash when the old Engine is destroyed.
For example:
In this case, two engines are used to display GIF images on the same page, when I remove the top flutterView and destroy the engine, the bottomEngine will continue to decode pictures, but it will be crash because io_manager is null
In addition, when I modified the code, I found that ImageDeocoder also had the same problem. In other words, there will be similar crash in certain situations ,please take a look