Thought on a slight change for MacOS?
buthed010203 opened this issue · 45 comments
This isn't so much an issue but more a proposal, I propose something similar to the code below be placed at the top of SDLApplication so that jars can be launched with a single double click rather than having to run it with java -XstartOnFirstThread -jar <jar>
every time. The code functions fine in its current state here but that would be required in every project using arc so I think it would be better to just integrate it directly into arc. All it does is relaunch the jar with the same arguments it was originally passed.
It's better than crashing, at least.
Okay, I will port it into that file and make a pr then I guess.
Actually now that I think of it, this poses a problem. I cant get the arguments that were passed to the program through the main method..
It's fine if you put it in Mindustry instead, it's not as if Arc will be used for anything else by me.
I just added an optional argument to sdlapplication
Wait, hold on.
This should be checking the JVM arguments, not the command-line arguments. Your change would make the application restart even when you run it with -XstartOnFirstThread -jar
, which would be undesirable (the Steam version would always relaunch, for example, which would likely cause problems)
Ive reworked it so that it only happens when the application crashes, theres no way to detect -XstartOnFirstThread reliably hence why i pass it an additional -firstThread argument.
Ive reworked it so that it only happens when the application crashes
XstartOnFirstThread crashes can look really weird on MacOS; how are you detecting these?
The reason it crashes is because of the window == 0 check throwing a new sdlerror, i just overwrote it
I'm unaware as to how it affects the steam version but I guess I can try it on an old non m1 mac I have lying around when I get home. I doubt it will cause any problem though considering i'm doing something similar on my windows machine already and everything still works
The only problem now is that it will get stuck in a loop if you don't pass the args to sdlApplication.
Hm wait no I covered that case by just crashing already lol
With this solution the steam thing is actually a non issue as it already has -XstartOnFirstThread passed so it should never crash there anyways
Ugh not this again... Its deciding to randomly work sometimes and then not work other times
The reason it crashes is because of the window == 0 check throwing a new sdlerror
In my experience it would just make the JVM explode.
It always makes it to B and aborts or makes it all the way through, very strange
https://forums.libsdl.org/viewtopic.php?t=6738 Interesting
I don't think there's a reliable way to detect crashes here.
Here's what you could do:
- Assume that anyone running the jar is not doing it through the bundled JRE, since that adds in the arguments by itself
- Use reflection to access the Java management API and check if
-XstartOnFirstThread
was supplied - If reflection fails, as it would in the Mindustry JRE, do nothing - I don't include the java.management module to save space
Here's what you could do:
- Assume that anyone running the jar is not doing it through the bundled JRE, since that adds in the arguments by itself
- Use reflection to access the Java management API and check if
-XstartOnFirstThread
was supplied- If reflection fails, as it would in the Mindustry JRE, do nothing - I don't include the java.management module to save space
I have considered that second solution but the problem with that is that it is supposedly unreliable. What about just bundling the -firstThread argument on steam and itch the way i was originally?
it is supposedly unreliable.
In what way?
What about just bundling the -firstThread argument on steam and itch the way i was originally?
I'd rather not, it doesn't solve the problem of someone just launching the JAR with -XstartOnFirstThread
.
In what way?
I cant find the posts that mentioned it but a couple of the ones I found when I originally tried this a few months back mentioned that it wouldn't work on certain systems.
I'd rather not, it doesn't solve the problem of someone just launching the JAR with
-XstartOnFirstThread
.
I don't really see the problem with this though. It restarts before the gui is even created and takes a tiny fraction of a second to restart so its not even noticeable.
I suppose another solution would be to use jni or something to call a c function to identify which cpu core the thread is running on however that is... janky.
it wouldn't work on certain systems.
...but you're only targeting Java 8+ on MacOS specifically, was it known to fail on those? I don't see a problem.
I don't really see the problem with this though.
It might run with the wrong java executable or the wrong VM arguments or cause other problems related to re-launching Java. I just don't like it.
...but you're only targeting Java 8+ on MacOS specifically, was it known to fail on those? I don't see a problem.
I have no idea on the specifics of this supposed unreliability but i suppose its worth trying
It also seems like libgdx might actually have a fix for it? libgdx/libgdx#6673
I don't use GLFW, LWJGL or AWT, so libgdx's solution isn't worth investigating.
damn it
Hmm... it doesnt seem to work, my jdk doesnt set the JAVA_STARTED_ON_FIRST_THREAD_...
variable
It appears that it doesnt work on either azul or temurin
I still think that the best solution would be to use an additional command line argument here considering its reliable
my jdk doesnt set the JAVA_STARTED_ON_FIRST_THREAD_... variable
What is "JAVA_STARTED_ON_FIRST_THREAD_
"? What does getInputArguments()
return in your tests? Does it return anything at all?
JAVA_STARTED_ON_FIRST_THREAD_12345
indicates whether or not the program with pid 12345 is on the main thread.
I haven't really looked at getInputArguments but i think its just the stuff passed to the main method
I just tried that approach on my VM with adoptopenjdk 16, and it worked. What does your code look like?
Which approach did you try?
- Launch with
-XstartOnFirstThread
- Get
ManagementFactory.getRuntimeMXBean().getName().split("@")[0];
- Check that
System.getenv("JAVA_STARTED_ON_FIRST_THREAD_" + pid);
is1
Is it null when you dont run it with that parameter?
I can't really check since this was run through the JS console on my crappy VM, and I can't use the console without the argument.
Amazing lol, lemme go find out
ffs thats what it was.., thats pretty dumb
Ok, i think im done