Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a stale_age to mkpidlock #491

Merged
merged 1 commit into from
Jul 11, 2024

Conversation

fingolfin
Copy link
Member

Normally the pidlock should be held for just a few seconds; waiting for
its age to exceed 60 seconds until we consider it stale should be safe.
In fact Julia waits 5 times longer if the process creating the pid lock
file seems to be still running.

On the other hand, without a stale age, the lock file is never
considered stale, even if the process creating it definitely is gone,
and so the user can get stuck, which obviously is very bad. To get
unstuck they need to manually delete the lock file.

Actually, I am not completely sure if the limit I provide is "good",
so if you think something else is more appropriate, please don't
hesitate to just adjust the PR or ask me to adjust it.

Normally the pidlock should be held for just a few seconds; waiting for
its age to exceed 60 seconds until we consider it stale should be safe.
In fact Julia waits 5 times longer if the process creating the pid lock
file seems to be still running.

On the other hand, without a stale age, the lock file is *never*
considered stale, even if the process creating it definitely is gone,
and so the user can get stuck, which obviously is very bad. To get
unstuck they need to manually delete the lock file.
Copy link
Member

@benlorenz benlorenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The time for the initialization is very hard to estimate, usually just a few seconds.
When there are many polymake wrappers to rebuild it might go over 5 min on a slow machine but that should be very rare (and I dont think anyone will run into issues with multiple processes in such an environment).

@benlorenz benlorenz merged commit e22a1f9 into oscar-system:master Jul 11, 2024
21 checks passed
@fingolfin fingolfin deleted the mh/mkpidlock branch July 26, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants