I'm not sure if this is the right way, please correct me if it's not:
In main loop, I poll events like this:
Keyboard.poll();
Mouse.poll();
// process the events
Then at the end of the main loop, I have Display.update() to swap buffers etc, and Display.sync(60) to keep FPS.
Now the question is, since Display.update() apparently also polls inputs, does this mean I'm going to lose some events? Should I remove the additional poll's and rely on Display.update()?
You can call Display.update(false), which does not poll inputs. However if you do, poll by calling Display.processMessages(), not individual devices.
Related
Scenario
There is a factory that receives orders. Once received, every order item goes through a multi-step production process. Every step is done by a separate machine and every machine can only handle one item at a time. So the order comes in, the first item goes to machine1, when it's done it goes to machine2 and the next item to machine1, etc.
Technical part
Every machine is implemented as a thread and has a queue with all items lined up that need this step of the process next. The run method of the machine checks in an endless while loop if there is anything in the queue, if yes it will handle that item, sleep for a certain amount of time and then push the item to the queue of the next machine.
Questions
In my head, this sounds all pretty simple. But I constantly run into null-pointer errors and other weird exceptions. I honestly don't fully understand what's wrong but I suspect it's a problem with multi-threading vs. sleep. At this point I got two questions:
What happens if I call a method of a sleeping thread (machine)? (Example: I call machine.addItemToQueue() while that machine is working on another item).
Follows Q1: Let's say I really can't call that method while the machine 'sleeps'. How else would I handle this? Should I take the queue outside the machine? Is this an async problem?
I have a process that splits into many different branches. The business requirement is that at any step, the process has to sent back to the process originator for correction and re-approval.
I know it would be possible to to use gateway logic at the end of each step and have the process return to the beginning that way; however, this would add many lines and branches to the process so that it would be incredibly difficult to read. I was thinking that an alternate way to accomplish this would be to simply abort the process and restart based on the information in the existing process - this seems more maintainable.
Both of these would not be too hard to implement, but I am wondering if there is an easier way to achieve this goal. I have not worked with signals much, but is there a way to leverage that to return to a previous step in the process?
Start of Editted Solution
Based on #Kris Verlaenen suggestion, it created the example process below.
I started by putting all of the steps that can be might be skipped into an Embedded SubProcess. The Return, Rejection, and Cancel signals were added from the Boundary Events tab of the palette. While the process waits for the Supervisor or Manager approval to complete, you can send a either of the signals to either go back to the first step or jump to the end of the process.
Using a event sub-process could allow you to trigger some part of your process every time the event occurs (could be signal, error, etc.)
Using an embedded sub-process with boundary event might help, as that way you would only have to link back grom that boundary event to the start, and whenever a signal / error occurs inside the sub-process, the boundary event could catch this. You could even make it interrupting, meaning it would cancel anything inside the sub-process as well, basically resetting what you were doing.
I'm fairly new to java and I was creating a program which would run indefinitely. Currently, the way I have the program set up is calling a certain method which would perform a task then call another method in the same class, this method would perform a task then call the initial method. This process would repeat indefinitely until I stop the compiler.
My problem is when I try to create a GUI to make my program more user friendly, once I press the initial start button this infinite loop will not allow me to perform any other actions -- including stopping the program.
There has to be another way to do this?
I apologize if this method is extremely sloppy, I sort of taught myself java from videos and looking at other programs and don't entirely understand it yet.
You'll need to run your task in a new thread, and have your GUI stuff in another thread.
Actually, if you keep working on this problem, you'll eventually invent event driven programming. Lots of GUI based software, like Android, use this paradigm.
There are several solutions. The first that comes to mind is that you could put whatever method needs to run forever in its own thread, and have a different thread listen for user input. This might introduce difficulties in getting the threads to interact with each other, but it would allow you to do this.
Alternatively, add a method that checks for user input and handles it inside the infinite loop of your program. something like below
while(true){
//do stuff
checkForUserInput();
//do other stuff
}
To solve this problem, you need to run your UI in another thread.
Many programs are based on an infinite loop (servers that keep waiting for a new user to connect for example) and your problem isn't there.
Managing the CPU time (or the core) allocated to your infinite loop and the one allocated to take care of your UI interactions is the job of the operating system, not yours : that's why your UI should run in a separate thread than your actual code.
Depending on the GUI library (Swing, ...) you're using there may be different ways to do it and the way to implement it is well answered on Stack Overflow
I've got two separate methods that will return with some data asynchronously, however I want to them collate that information and send it elsewhere as one call.
The way I see it, I could either:
Make the method that submits the data after its recieved wait until it has recieved both sets of information or, quit after x amount of time if it has been waiting.
OR
Make a the methods that receive data call the submit method, if the other data has been received.
Obviously depends upon implementation, but neither of these feel like brilliant solutions.
Make the method that submits the data after its recieved wait until it has recieved both sets of information
If this method is on the main thread then don't do this unless absolutely necessary. In which case, you want to show some progress dialog.
quit after x amount of time if it has been waiting.
Mostly likely you don't want to do this. It stinks of bad design.
Make a the methods that receive data call the submit method, if the other data has been received.
This you could do and set some flag to know that one is done. What you might want is an interface. If you are using an AsyncTask for your asynchronous work then this answer can help with that
I am currently working on a project in JAVA where I have to make an agent to interact with a server.
Each 50ms, the server will receive the last thing I outputted to System.out and send me a new set of lines as a 'state' through the System.in printstream to analyze and send my next message to System.out.
Also, if the server receives multiple outputs from me, it only regards the most recent one.
..
As for my question:
My program originally constructed a tree and then analyzed each leaf node to see which would be optimal, and then waited around for the next input, but I can recursively do a deeper tree search that would make my output 'better' (and again and again to keep returning a better result).
Using this and the fact that if the server receives multiple outputs, it only takes the most recent one, I could do each level, print my result and start the next level. But here comes my problem...
I can't be stuck in some complex algorithm while I am supposed to receiving the next input as I will then miss it. So I was wondering if there is a way to cancel anything else I am doing when I receive something via System.in and then go back to the beginning of the function and start the search again with the new set of input (and rinse and repeat..)
I hope this all makes sense,
Thank ye all
You absolutely require either multiple threads (or multiple processes) here.
I assume that you've solved the problem of receiving input into System.in, as well as the problem of your algorithm. The next step is to package each in a Runnable interface, and hand each a reference to a queuing object. This will scaffold a Producer-Consumer relationship.
Whenever your listening Runnable (the Producer) gets a message, it needs to put it on your queue. After every unit of work, your algorithm (the Consumer) should look into the queue for items that are there. If it finds something, it should integrate it as normal. If not, it continues on with it's work.
Both the Producer and the Consumer need to be started in their own threads and allowed to run concurrently.