Hi David, On Mon, Oct 22, 2018 at 9:00 PM David Lloyd <david.ll...@redhat.com> wrote: > > 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. >
I understand. Sorry for being stubborn. I have spent so much time debugging Runtime.exec() problems in the past that I am very paranoid about changes. Bugs in the Runtime.exec() layer tend to be so very hard to analyze. That said, as I wrote in my earlier mail, I think using posix_spawn() may be fine. If I understand the glibc coding correctly, we are good down to glibc 2.4, which is quite old. This will also save me a lot of work, since upstreaming our patch would have been a real pain. It is tightly interwoven with other proprietary components and would have effectively been a rewrite. So I think yes, your patch is fine. Lets get it in and test it. Best Regards, Thomas > -- > - DML
