On 15 August 2010 21:32, Nikola Knezevic wrote: > On Aug 15, 8:54 pm, björn wrote: >> > I took a look at the code. I can't figure out why the problem occurs, >> > but I solved it by using double-fork(). This way, I ensure that MacVim >> > process becomes a child of init. Double fork()-ing is often used when >> > you want to make sure that the child doesn't inherit anything from the >> > parent. >> >> > Here is the patch I used, let me know if it works for you: >> > <http://lpd.epfl.ch/knezevic/setsid.patch> >> >> Thanks. I'll take a look at it but not before the 7.3 release...we've >> had some severe fork-related problems in the past so I don't dare to >> include this without some testing first. > > That sound ok :) > >> I don't at all understand these forking issues (indeed I don't >> understand why we can't just leave out the setsid() call since this >> also gets rid of the problem). Does double-forking have any obvious >> negative side effects? > > There are no negative side effects of doing double forking. It is a > useful technique when you want to make sure the process doesn't have > controlling terminal, and to fight off zombies the easy way (init will > reap them). > > Can you explain me what is the intention of macos_fork()? What do you > want to achieve? I'm trying to understand the intention, to see > whether setsid is really important.
Ahem, well, gvim traditionally forks by default and hence MacVim forks as well...that's pretty much all that I know. Nico Weber wrote that code so he may have a better answer (if he's still reading this list?). Sorry, I can't give you a better answer than this but it is beyond my current understanding. Björn -- You received this message from the "vim_mac" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
