On 15 August 2010 21:55, björn wrote: > 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.
I've merged this patch now. Let's be on the look out to see if it causes any problems. 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
