Front page | perl.perl5.porters |
Postings from May 2016
Leon Timmermans <fawaka@gmail.com> wrote: > It appears we removed vfork support 15 years ago in 52e18b1f. I think the > concept of it is out-of-date, and using it correctly is fickle. I don't > think it's a good idea. Sadly, in the past 15 years process sizes have gotten bigger and make it more expensive to fork. > It may actually be sane to implement system on top of posix_spawn though > (which can use vfork internally). That at least can be reasoned about, and > seems to generally do what we want (I've never actually used it, there may > be pitfalls that aren't obvious yet). Good point, I'll give posix_spawn a shot if nobody beats me to it. It could be a few months or even years for me, though. Ruby doesn't use posix_spawn since it needs to support chdir/rlimits/umask and a bunch of other things in its generic Process.spawn API (which system() shares code with); but Perl doesn't do those things, so I suppose it's fine for Perl. > Not sure either option is really worth the development effort though, any > program where fork is a serious bottleneck is likely to be a mess anyway > unless you're writing a shell or make. Who knows what I'll be working on :> But yeah, I plan to look at getting the dash shell to support posix_spawn or vfork, too; and maybe bash/GNU make, too (but FSF copyright assignment is a pain).Thread Previous | Thread Next