tag:blogger.com,1999:blog-6042417775578107106.post1060299184678794..comments2023-08-05T11:30:32.754-04:00Comments on The Hacks of Life: fork + execve - so happy together!Chrishttp://www.blogger.com/profile/14648675681957285299noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6042417775578107106.post-62399831364186636342009-12-17T23:49:21.364-05:002009-12-17T23:49:21.364-05:00the real issue is expecting things from fork it ne...the real issue is expecting things from fork it never promised... <br /><br />besides fork has always been something you need to be careful with and make sure you know what you're doing and what it gives you.<br /><br />ie it is still a reasonable thing to write a pre-forking (or just a forking) server of some kind (ie webserver), sure threads are faster, but forking gets you free cleanups every so often so your bugs are less severe (like memory leaks or crashes)<br /><br />If all you expect to get cloned is your memory and file descriptors then fork works, if you have some other state outside your app you need to deal with it yourself.<br /><br />OSX's issue seems to be that some Apple libraries unexpectedly (at least for some people) have state out side the process using them that does not get copied by fork.Spudd86https://www.blogger.com/profile/14244419906019394320noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-1746035090762172112009-12-17T23:33:09.098-05:002009-12-17T23:33:09.098-05:00If you think about it some stuff doesn't make ...If you think about it some stuff doesn't make any sense with fork... like GUI apps (think about apps on linux with an X GUI... what happens to that when you fork...)<br /><br />Basically if there is state outside the process that is not file descriptors or something that the kernel knows about and can clone then it doesn't get copied (and really why would you want to fork such an app...)Spudd86https://www.blogger.com/profile/14244419906019394320noreply@blogger.com