emcmodule: retry the tool mmap attach in stat.poll()

[grandixximo]

Fixes #4656.

The first stat.poll() in a process tried tool_mmap_user() once; if task had not created ~/.tool.mmap yet, a static flag latched and every later poll() returned NULL without an exception (SystemError forever). ui-smoke polls before task is up, so isolated runs (#4648) failed with task not ready within 60.0s.

• poll() retries the attach until it succeeds; initialized stays 0 meanwhile, so tool_table/toolinfo report no data. Correction to my issue comment: a NULL base is not safe in tooldata_get() (it exits), which is why the gate stays.
• tool_mmap_user() warns once and treats a file shorter than the mapping as absent (creator truncates before extending; mapping it then would SIGBUS).
• drive.py: drop the comment calling the SystemError normal.

Tested in a sandbox with a fresh HOME and no ~/.tool.mmap: ui-smoke axis fails on master with the issue's error and passes with this; tests/ui-smoke plus tests/*tool* 20/20. With this, the touch $HOME/.tool.mmap in #4648 should not be needed.

[BsAtHome]

The real problem is that the progression is an effective race.

[grandixximo]

Agreed. The launcher is racy: loadusr -Wn inihal returns at the hal_ready() in ini_hal_init(), before motion and interp init and before Task::Task() calls tool_mmap_creator(). halui starts in that window and calls tool_mmap_user() exactly once, so it can lose and keep a NULL base. hal_ready() cannot move later because task's motion init waits for the HAL files that load after it. I can create the file in task before ini_hal_init() so everything the launcher starts finds it; the retry in poll() stays for clients started outside the launcher (ui-smoke's drive.py, user scripts). Do you want that in this PR or as a follow-up?

[BsAtHome]

It should be safe to cast to size_t since most syscalls use that for file size (and ssize_t if errors are to be returned). Then you don't need intmax_t as it is unclear what size int actually is. However, off_t must encapsulate at least ssize_t or the syscall would no longer be 64-bit safe.

[grandixximo]

Done, compared and printed as size_t; the intmax_t and <stdint.h> are gone.

[hdiethelm]

Thanks a lot for fixing this!

It was also the reason the other tests failed, probably due to the zero size .tool.mmap in my work around, but there was no understandable error message in this case.

I cherry-picked the commits in my branch, dropped the workaround and it works nicely. Except some other bugs from my PR... ;-)

Just one thing:

tool_mmap_user(): tool mmap not available: /home/hannes/.tool.mmap: open: No such file or directory
poll(): tool mmap not available yet, retrying

I would expect a 3. message:
poll(): tool mmap available now
so it is clear that all is fine. Otherwise, it looks like an error.

I had a hard time discriminating between errors and warnings in the CI logs. And it also took me some time to discover that tool_mmap_user(): tool mmap not available was the reason the test failed.

[grandixximo]

Thanks for testing it. Added: after the first warning, poll() now prints poll(): tool mmap available now once the attach succeeds.

[grandixximo]

Correction to my earlier reply: I misread the startup order. task's main() runs emcTaskOnce(), whose Task::Task() calls tool_mmap_creator(), before emctask_startup() reaches ini_hal_init() and its hal_ready(). So loadusr -Wn inihal only returns after the file exists, and halui and the GUI started by the launcher always find it. The race only affects clients started outside the launcher, like ui-smoke's drive.py or user scripts, and the retry in poll() covers those. No follow-up needed.