Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (511)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Best way to handle console commands without stalling?  (Read 966 times)
0 Members and 1 Guest are viewing this topic.
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Posted 2013-11-10 20:50:16 »

I'm using the LWJGL for a new project, but it's not for a game, exactly. The point is that this project is meant to take in lines from the console piped from some other device. It's not important what the other device is, but the point is that a few times a second this device will write a string to the command line, which is then piped into my program.

What's the best way to handle these string inputs? Provisionally, I am using the scanner, calling "scanner.nextLine()" to read the next line. The problem is that this will pause the program until a new line is written onto the console, which is NOT what I want.

I would rather have the program run as normally, at 60fps or what have you, and IF a new line was written to the console, to THEN call a method using that new string as input.

What is the best way to implement this?

Thanks
Offline Phibedy

Senior Duke


Medals: 9



« Reply #1 - Posted 2013-11-10 21:01:52 »

I would use a thread which is listening and adding incoming strings to an arraylist and each rendercall I would poll the list from the mainthread.
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Reply #2 - Posted 2013-11-11 00:41:50 »

I didn't really know about Threads but I took a few hours to research it and made something that works. Thanks!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Reply #3 - Posted 2013-11-11 02:53:55 »

Oh wait, alls not well. I just realized that even though my window closes when I click "x", my program keeps running, because in one thread I'm still waiting for scanner.nextLine(). When I type something into the console, the program ends as it should. How do I get my program to end before nextLine() gets what it wants?

Thanks
Offline bilznatch

Senior Duke


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #4 - Posted 2013-11-11 03:27:47 »

Make it only check for nextLine while running = true, then before you close the window using the command, change running = false.

I think at least.

EDIT: This will of course require a boolean being added, and adding this to your thread that does the process.
EDIT 2: Apparently you can use interrupts as well. Link below.
 http://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Reply #5 - Posted 2013-11-11 03:38:37 »

I do not understand. Here is what the structure of my "reader" looks like, one of the two Runnables being run in it's own thread.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
public class Reader implements Runnable {

   Scanner sc = new Scanner(System.in);
   @Override
   public void run() {
      while(true){
         String input = sc.nextLine();
         MainClass.otherRunnable.pause();
         
         //Until the other thread is done, sleep for a bit and check again...
         while(!MainClass.otherRunnable.hasStopped){
            try {
               Thread.sleep(2);
            } catch (InterruptedException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
            }
         }
         
         doSomething(input);
         
         MainClass.otherRunnable.resume();
      }
   }

}


What would you change?
Offline bilznatch

Senior Duke


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #6 - Posted 2013-11-11 03:49:16 »

-snip-

I would make it look like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
public class Reader implements Runnable {
        boolean mainRunning = true;
   Scanner sc = new Scanner(System.in);
   @Override
   public void run() {
      while(true && mainRunning){
         String input = sc.nextLine();
         MainClass.otherRunnable.pause();
         
         //Until the other thread is done, sleep for a bit and check again...
         while(!MainClass.otherRunnable.hasStopped){
            try {
               Thread.sleep(2);
            } catch (InterruptedException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
            }
         }
         
         doSomething(input);
         
         MainClass.otherRunnable.resume();
      }
   }

}

then, when I created the thread, I would pass the running boolean = false from the main thread to it before closing, so that it wouldn't run it's while loop, as the main thread would be stopped, so you would never sleep the secondary again. This would look like this:
1  
2  
3  
4  
5  
//on create
Reader reader = new Reader();
//on close
reader.mainRunning = false;
System.exit(0);


*This is highly speculative, I'm no good at threads either. I'm pretty sure it works though.
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Reply #7 - Posted 2013-11-11 03:54:57 »

All I needed to do was insert "System.exit(0)" when I wanted the program to stop. Forgot about that command, thanks!
Offline nerb
« Reply #8 - Posted 2013-11-11 03:58:20 »

I would make it look like this:
1  
while(true && mainRunning){...}


I'm pointing out the obvious, but just "while(mainRunning)". The "true &&" bit is redundant.

All I needed to do was insert "System.exit(0)" when I wanted the program to stop.

I don't know if others would agree, but an endless while loop is a bit of sloppy code. It's best to terminate your loops gracefully using a boolean flag, as bilznatch has mentioned. Either way... whatever works for you. EDIT: Or does sc.nextLine() block? I see what you're doing there. Sorry.
Offline CodeHead

JGO Knight


Medals: 41


From rags to riches...to rags.


« Reply #9 - Posted 2013-11-11 15:01:17 »

All I needed to do was insert "System.exit(0)" when I wanted the program to stop. Forgot about that command, thanks!

Look into Thread.setDaemon(). When you mark a thread as a daemon thread, it will not prevent the JVM from closing when your user thread(s) terminates. It addresses the situation being discussed without having to throw interrupts, juggling booleans, or forcing a JVM exit. Just make sure you call the setDaemon method before starting the thread.

Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bilznatch

Senior Duke


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #10 - Posted 2013-11-11 22:25:43 »

Is that all daemon threads do? I've heard about them, but I never looked into them.
Offline CodeHead

JGO Knight


Medals: 41


From rags to riches...to rags.


« Reply #11 - Posted 2013-11-11 23:05:53 »

Pretty much. Their main purpose is to service user threads, therefore once all of the user threads are dead, they have no reason to stick around and the JVM happily disposes of them. The main caveat to be aware of when using them is that there is no finalization performed by the JVM when it kills a daemon thread so any cleanup code you may have in a "finally" block will never get triggered. This limits their usefulness somewhat, but  it presents a straightforward and practical solution for the situation being discussed. Smiley

Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
Offline bilznatch

Senior Duke


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #12 - Posted 2013-11-12 01:04:17 »

Alright sweet, thanks for the explanation. That's why I love this forum, learn a new thing everyday.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (42 views)
2014-10-16 15:22:06

Norakomi (32 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (58 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (85 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!