英文:
Changing directories in go routines
问题
我正在尝试在一个go routine中切换到目录x。现在我想使用另一个go routine将目录切换到目录y。这个第二个go routine中对当前工作目录的更改会影响到第一个go routine的执行吗？我之所以想这样做是为了在执行类似任务时引入并行性。如果它确实改变了当前工作目录，那么应该采取什么替代方法（如forking...）？
英文:
I am trying to change directories in a go routine to directory x. I now want to use a different go routine that changes the directory to directory y. Will the execution of my first go routine be affected by this change to the current working directory in the second go routine? The purpose of wanting to do this is to introduce parallelism while doing similar tasks. If it does end up changing the CWD, what should be an alternative approach (forking...)?
答案1
得分: 5
如评论中所提到的，每个goroutine中跟踪当前工作目录会导致问题。
尝试使用filepath.Abs来获取绝对目录并将其存储起来。然后，每个goroutine可以在自己的目录上操作，而不必担心在幕后进行“切换”。只需确保不会出现多个goroutine意外修改同一文件的情况。
编辑：根据@Evan的评论，删除了一部分文本。使用绝对路径 :p
英文:
Like mentioned in the comments, keeping track of the current working directory in each goroutine will cause problems.
Try using filepath.Abs to capture the absolute directory and store that instead. Then each goroutine can operate on it's own directory without worrying about it being "switched" under the hood. Just be sure you're not modifying the same file accidentally by multiple goroutines.
Edit: Removing a chunk of text per @Evan's comment. Use absolute paths :p
答案2
得分: 1
@Evan指出了尝试使用“更改工作目录”（CWD）系统调用存在的一个根本性缺陷。
我认为@Evan是正确的，CWD是某些操作系统上的线程属性。
正如@Evan指出的，一个goroutine可能会被重新调度（例如在函数调用、通道访问或系统调用时）到另一个线程上。
这意味着，如果Chdir()可以更改线程的CWD，那么更改CWD可能是不可能的，因为Go的运行时选择在不可见和不可预测的情况下将goroutine重新调度到另一个线程上，从而导致其CWD发生变化。
编辑：我不希望Chdir()做除了更改进程的CWD之外的任何其他操作。然而，该包的文档中没有提到“进程”。
更糟糕的是，运行时可能会在发布版本中改变工作方式。
更糟糕的是，这将非常难以调试。这可能是一个“海森堡问题”，任何尝试调试它的方式（例如调用一个函数，运行时可能将其用作重新调度点）都可能以不可预测的方式改变行为。
跟踪绝对路径名。这是明确的、清晰的，甚至可以在不需要同步的情况下在goroutine之间工作。因此，它更简单，更容易进行测试和调试。
英文:
@Evan has identified a fundamental flaw in attempting to use the 'change working directory' (CWD) system call.
I believe that @Evan is correct, and that the CWD is a thread property on some OS's.
As @Evan pointed out, a goroutine could be resheduled (for example at a function call, channel access, or system call) onto a different thread.
The implications are, it may be impossible to change the CWD (if Chdir() could change the threads CWD) because Go's runtime chooses to reschedule the goroutine on a different thread; its CWD could change invisibly and unpredictably.
Edit: I would not expect Chdir() to do anything other than change the CWD for the process. However, the documentation for the package has no mention of 'process'.
Worse, the runtime may change how things work with releases.
Even worse, it would be very hard to debug. It may be a 'Heisenberg problem', where any attempt to debug it (for example by calling a function, which the runtime may use as a reschedule point) may actually changes the behaviour in an unpredictable way.
Keep track of absolute path names. This is explicit, clear, and would even work across goroutines without any need for synchronisation. Hence it is simpler, and easier to test and debug.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论