You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interesting! I just tried using callr::r_bg and cannot reproduce it. My test above is in two processes within the same emacs/ess, do you think it's possible that somehow the process group or process-parent is confounding the logic?
No, the fnctl(2) manual page [1] does not say anything about locks being inherited or shared. (Although they might ignore forking a process without executing another, so if you're doing that that might explain this.)
It is also very weird that this would depend on the file name.
I can't see anything in the source that would contribute to this behavior. Further ... odd ... I can no longer reproduce the behavior above. Further odd since I tested it a dozen times (same code) before starting this issue. :-/
The correctness of locking is contingent on simple file patterns.
Side-by-side, two R processes on the same host, code executed from top to bottom in order.
Correct behavior:
Same path, slightly different filename:
The underlying filesystem is local (
/
) and isext4
. R-4.3.2, filelock_1.0.3, in a single emacs/ess instance.The text was updated successfully, but these errors were encountered: