site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 27 Jan 2008, at 20:56, Peter Seebach wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... In message <479CD1DB.4030504@yahoo.com>, Steve writes: So, are you suggesting then it could well be a bug with Leopard (it works fine on Tiger and, it works fine as coded by simply removing the v from vfork)? Obviously, the simple solution on Leopard for now is to use fork. I shall proceed to make a small test program and submit to Apple then. I wouldn't consider it a significant bug; vfork is deprecated, having been a performance hack to improve performance on the VAX. The existence of modern systems with copy-on-write semantics makes it a waste of time to try to make things work with vfork That's more or less true for Linux, but not for Mac OS X at least up till 10.4.x (I haven't benchmarked on 10.5 yet). Compiling our compiler with itself, which involves about 173 (v)fork+execs from a single compiler run to assemble&link all the files, is 20% to 25% slower with fork instead of vfork on a G4, and 35% to 40% on a G5 (32 bit processes in both cases) on 10.4.x. And for clarity: this is relative to the entire time needed for compiling+assembling+linking everything (on the G5: 24 vs 15 seconds), not some academic mbench- like speed difference between the fork and vforks. Copying the memory maps is extremely expensive on Darwin (at least in the versions I tested on), and gets progressively more expensive the more memory the program has allocated. The modern alternative is obviously posix_spawn, but we cannot use that since we still support 10.3.x (it even probably even still works on 10.1 and 10.2 as well, but I don't test those anymore). This email sent to site_archiver@lists.apple.com