Optimize 'enter' and 'run' for a container getting initialized #1495
Conversation
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
d45d993 to
b34979d
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 6m 42s |
There's no immediate desire to make Toolbx work on operating systems that don't use forward slashes as path separators. However, there's also no reason not to use the standard library. containers#1495
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
b34979d to
c610860
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 6m 31s |
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
e40d3a3 to
d3bd5e9
Compare
|
Build failed. ✔️ unit-test SUCCESS in 6m 48s |
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
d3bd5e9 to
ff6c146
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 7m 19s |
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
ff6c146 to
3c8f30a
Compare
|
Build failed. ✔️ unit-test SUCCESS in 7m 14s |
I will waive that |
Currently, the 'enter' and 'run' commands poll at one second intervals to check if the Toolbx container's entry point has created the initialization stamp file to indicate that the container has been initialized. This came from the POSIX shell implementation [1], where it was relatively easier to poll than to use inotify(7) to monitor the file system. The problem with polling is that the interval is always going to be either too short and waste resources or too long and cause delays. The current one second interval is sufficiently long to add a noticeable delay to the 'enter' and 'run' commands. It will be better to use inotify(7) to monitor the file system, which is quite easy to do with the Go implementation, so that the commands can proceed as soon as the initialization stamp file is available, instead of waiting for the polling interval to pass. There's a fallback to polling, as before, when the operating system is suffering from a shortage of resources needed for inotify(7). This code path can be forced through the TOOLBX_RUN_USE_POLLING environment variable for testing. Setting this environment variable disables some code to ensure that the polling ticker is actually used, because, otherwise, the race between the creation and detection of the initialization stamp file makes it difficult to test the fallback. [1] Commit d3e0f3d containers@d3e0f3df06d3f5ac containers#305 containers#1070
debarshiray
force-pushed
the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
from
3c8f30a to
d8289fb
Compare
debarshiray
changed the title
|
Build succeeded. ✔️ unit-test SUCCESS in 6m 16s |
debarshiray
deleted the
wip/rishi/cmd-run-prefer-fs-events-over-polling-to-ensure-initialization
branch
Currently, the
enterandruncommands poll at one second intervalsto check if the Toolbx container's entry point has created the
initialization stamp file to indicate that the container has been
initialized. This came from the POSIX shell implementation [1], where
it was relatively easier to poll than to use
inotify(7)to monitor thefile system.
The problem with polling is that the interval is always going to be
either too short and waste resources or too long and cause delays. The
current one second interval is sufficiently long to add a noticeable
delay to the
enterandruncommands.It will be better to use
inotify(7)to monitor the file system, which isquite easy to do with the Go implementation, so that the commands can
proceed as soon as the initialization stamp file is available, instead
of waiting for the polling interval to pass.
There's a fallback to polling, as before, when the operating system is
suffering from a shortage of resources needed for
inotify(7). This codepath can be forced through the
TOOLBX_RUN_USE_POLLINGenvironmentvariable for testing. Setting this environment variable disables some
code to ensure that the polling ticker is actually used, because,
otherwise, the race between the creation and detection of the
initialization stamp file makes it difficult to test the fallback.
[1] Commit d3e0f3d
d3e0f3df06d3f5ac
#305
#1070