On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe <thomas.stu...@gmail.com> wrote: > Hi all, [...] > So far I have not read a single technical reason in this thread why > vfork needs to be abandoned now
Note that my patch does not abandon vfork. It does not even change the default exec strategy away from vfork, nor does it cause any obstacle to your proposed change. It only adds the ability for users to opt in to the existing posix_spawn implementation on Linux. It's just a first step, in whatever direction we might be going, which is far from decided. As you and Martin have both implied, it's a good idea to be very cautious in this area. > The current posix_spawn() implementation was added to glibc with glibc 2.24. > So, what was the state of posix_spawn() before that version? Is it safe to > use, does it do the right thing, or will we encounter regressions? I certainly have not suggested making posix_spawn be the default on Linux at this time. But if we don't make it at least a possible option, it cannot be tested *at all*, by anyone, unless they're adventurous enough to hack OpenJDK themselves. The questions you ask can not be answered without at least making it a choice. There are many reasonable paths that can be taken after this patch is merged (if it is): • It could stop here and keep the status quo; users who have trouble with the current implementation can try out posix_spawn • The Linux port could be modified similarly to your proposal to use the existing jspawnhelper infrastructure with vfork on Linux, while still allowing posix_spawn to be manually selected • The Linux port could be modified to use posix_spawn if gnu_get_libc_version(3) and/or other run-time probes return an acceptable value, using vfork (either the original or your modified approach) otherwise, still allowing posix_spawn to be manually selected Other possibilities exist as well. Nothing in this email thread (AFAICT) invalidates your basic proposal, other than perhaps the observation that your proposal has similarities to the existing jspawnhelper path, so that could possibly be utilized. This patch only *increases* our possible future choices; it does not impose any restrictions. -- - DML
