Re-factor the PDFScriptingManager._destroyScripting method (PR 13042 follow-up)
#13074
Conversation
…2 follow-up) *Please note:* Given the pre-existing issues raised in PR 13056, which seem to block immediate progress there, this patch extracts some *overall* improvements of the scripting/sandbox destruction in `PDFScriptingManager`. As can be seen in `BaseViewer.setDocument`, it's currently necessary to *manually* delay the `PDFScriptingManager`-destruction in order for things to work correctly. This is, in hindsight, obviously an *extremely poor* design choice on my part; sorry about the churn here! In order to improve things overall, the `PDFScriptingManager._destroyScripting`-method is re-factored to wait for the relevant events to be dispatched *before* sandbox-destruction occurs. To avoid the scripting/sandbox-destruction hanging indefinitely, we utilize a timeout to force-destroy the sandbox after a short time (currently set to 1 second).
Snuffleupagus
force-pushed
the
scripting-refactor-destroy
branch
from
8b339bf to
52a5989
Compare
|
/botio integrationtest |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://3.101.106.178:8877/a0780c57e1c1bdb/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/23fe8e79bebaa87/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/23fe8e79bebaa87/output.txt Total script time: 3.10 mins
|
From: Bot.io (Windows)SuccessFull output at http://3.101.106.178:8877/a0780c57e1c1bdb/output.txt Total script time: 4.72 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/c8777a8653848e8/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/c8777a8653848e8/output.txt Total script time: 4.27 mins Published |
|
Thank you for improving this! |
Please note: Given the pre-existing issues raised in PR #13056, which seem to block immediate progress there, this patch extracts some overall improvements of the scripting/sandbox destruction in
PDFScriptingManager.As can be seen in
BaseViewer.setDocument, it's currently necessary to manually delay thePDFScriptingManager-destruction in order for things to work correctly. This is, in hindsight, obviously an extremely poor design choice on my part; sorry about the churn here!In order to improve things overall, the
PDFScriptingManager._destroyScripting-method is re-factored to wait for the relevant events to be dispatched before sandbox-destruction occurs.To avoid the scripting/sandbox-destruction hanging indefinitely, we utilize a timeout to force-destroy the sandbox after a short time (currently set to 1 second).