Hi Thomas,
A minor concern is the impact of the extra write and read that can cause
rescheduling
of the parent and child processes. But that's probably in the noise
compared to the
real work of exec. It would raise the complexity quite a bit/too much
to code a single read
in the parent that could expect 0/4/8 bytes.
At ProcessImpl_md.c: 708: the "Read failed" is less than informative.
(Though it is the same as the pre-existing one at 720).
But I suppose it has never happened. The 'Exec failed' is more specific
than 'read'.
And it has probably never been seen.
Thanks, Roger
On 06/04/2019 02:06 AM, Thomas Stüfe wrote:
Hi all,
may I please have reviews/opinions on this fix?
Fix has been live in our test landscape since some weeks.
If we do not want this fix to be in JDK13, we may want to revert the
posix_spawn-by-default-on-Linux change.
Thanks, Thomas
On Mon, May 20, 2019 at 4:15 PM Thomas Stüfe <thomas.stu...@gmail.com
<mailto:thomas.stu...@gmail.com>> wrote:
Hi all,
(old mail thread:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html)
May I please have your reviews and opinions for the following bug fix:
issue: https://bugs.openjdk.java.net/browse/JDK-8223777
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
<http://cr.openjdk.java.net/%7Estuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/>
---
The fix implements Florians proposal: the jspawnhelper will signal
its aliveness to the parent process the moment it gains control.
If the parent process does not get the signal, it assumes exec'ing
the jspawnhelper never worked.
I only do this for posix_spawn mode, out of cautiousness.
(Note that I kept the fix as minimal as possible. I found a minor
bug and some improvement possibilities and opened follow up issues
to track them: JDK-8224180 and JDK-8224181).
Thanks, Thomas
