On Wed, 16 Dec 2020 18:52:22 GMT, Matthias Bläsing
<github.com+2179736+matthiasblaes...@openjdk.org> wrote:
>> tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayerLauncher.java
>> line 44:
>>
>>> 42: new Thread() {
>>> 43: {
>>> 44: setDaemon(true);
>>
>> Ordinarily a good idea, but in this case it might be better without it. The
>> only way this can matter is if there is a case where all other threads would
>> return (thus stopping them) without any calls to `System.exit`. In that
>> case, the earlier code would report a timeout, while the new code would exit
>> with a normal (0) status. Not sure that's what we want.
>
> I tested the "bad" case. That means I removed the fix and I see the segfault,
> but the JVM does not exit - it exists after 15s with the timeout (error code
> 3), but not with the expected code 134. Someone looking at a segfault problem
> would then get the wrong information and look at the wrong code. That is
> fixed by making the process reaper a daemon thread.
>
> I could add another error return at the end of
> myapp7.DataUrlWithModuleLayerLauncher.main(String[]). That point should only
> be reached when all JavaFX windows are closed or the Platform is explicitly
> shutdown.
Oh, in that case, go ahead and leave it as a daemon thread. And yes, another
error exit in the launcher main should handle the problem I was worried about.
-------------
PR: https://git.openjdk.java.net/jfx/pull/360
