Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  Event-Thread  (Read 2739 times)
0 Members and 1 Guest are viewing this topic.
Offline zero

Junior Duke





« Posted 2007-03-25 08:32:17 »

Hey there,

does anybody know in which Thread, the ControllerListener is notified when a Controller is added/removed? In he AWT-Event-Thread?

I tried to figure it out by myself, by searching the cvs repo, but I cannot find a class which calls the ControlerEnvironment.fireControllerAdded/Removed methods.

Sorry, if my question is already answered in the JavaDoc, but I didn't find an actual one. To be honest, I got the binaries from the LWJGL, since these were the most recent I found...
Offline broumbroum

Junior Duke





« Reply #1 - Posted 2007-03-25 08:53:39 »

that's right, it uses the JVM Event Thread Dispatcher. What is your problem? Smiley

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline zero

Junior Duke





« Reply #2 - Posted 2007-03-25 10:00:45 »

just to know, when/whether I need to synchronize.

I mean the AWT-Event-Thread is fine for most applications, but if

 - I write a console application, everything has to be executed by java.awt.EventQueue.invokeXXX to get rid of synchronization
 - I use another window kit (e.g. the Java GTK wrapper) there might be two different event-threads and I have to synchronize both

Or did I get s.th. wrong?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #3 - Posted 2007-03-25 10:33:25 »

There are only 2 places that awt is involved in any jinput code, one is in the controller read test and the other is in the awt plugin. For normall applications using any of the native plugins, then no awt is present, unless you use the awt thread when you call poll or any of the other methods on jinput.

As for controller added/removed events, they are not implemented in any of the plugins as far as I am aware.

HTH

Endolf

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #4 - Posted 2007-03-25 10:52:20 »

A quick hunt through the code would show that there are a number of threads that jinput creates. A number of shutdown hook threads, so you should be able to ignore those. One of the windows plugins creates a thread, but that plugin is disabled by default, and the Linux plugin also creates one.
The linux one is due to the fact that you have to use the same thread for interactions with force feedback effects through out the life of the effect.

Other than those, any thread working in jinput is what ever thread you used to make the api call. All of the synchronisation should happen within the jinput code, so you should effectivly be able to treat it as a single threaded API. Should the controller listener events ever get fired, they will most likely happen as part of a call to poll, so will call back using the same thread you used to call poll again.

HTH

Endolf

Offline zero

Junior Duke





« Reply #5 - Posted 2007-03-25 11:40:49 »

Thanks for the information endolf,

That explains why I couldn't find any calls to the methods firing events.  Wink

However, I wonder in which thread the events are dispatched, if implemented by a pulgin? (It's in the API so, you probably have though about this)
IMO it should be consistent for all plug-ins, since one almost never uses them directly.

Beside removing the add/remove listener methods, the two solutions are:

- A dispatch method should be added to the abstract ControllerEvironment class, which dispatches the events in the caller thread (compare  to SWT). Of course the implementation should be thread safe, so it can be used from different ones.

- A dedicated JInput Thread should run in the background, and the should be similiar synchronized static methods like provided by the java.awt.EventQueue. As a result, every Jinput code must be executed in this Thread (compare to AWT).

The latter one is clearly easier to implement, but more difficult to use. E.g. the user has to synchronize everything with the AWT-Event-Thread if using this window toolkit. Same with SWT, unless all SWT code is executed in the JInput-Event-Thread via the invokeXXX methods.

[update]
just read the previous post:  dispatching in the poll method is similiar to the first and I good point is that when the polled controller removing is checked anyway for this one. On the other side, checking for all controller adds and removes within a poll, which is probaly done for each controller in each frame, is probably an overhead compared to a single call to dispatch, isn't it?

An idea would be adding a callback interface to a newly added ControlEnvironment.dispatch method, which allows to poll the connected invidual controllers and optinally remove the method from the Control class.
[/update]

Just thoughts, I don't need the events atm. :-)
And I kow that such things are difficult to implement correctly regarding threading, since I had to implment a firewire cameras, inclding listening to changes the bus...
Offline broumbroum

Junior Duke





« Reply #6 - Posted 2007-03-25 14:38:19 »

Not to bring you to a wrong orientation, SYNCHRONIZING means to manage objects-accesses by the JVM, then it is quite clear that one accessed by one Thread shouldn't be modified AT THE SAME TIME by another one. So we use SYNCHRONIZED clauses to LOCK access to an identified object while another one will WAIT FOR UNLOCKING. It is important to consider that another cannot wait for access unexplicitely, I mean, when it is called by a wait() or join(). Thus synchronized code would appear like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
//(somewhere in one Thread or Class)
synchronized (objectToLock) {
     // some code
    objectToLock.someMethod(); // this method can be a BLOCKING method
    // eventually call notfiy
    objectToLock.notify();
}

//(somewhere else in another Thread or Class)
synchronized(objectToLock) {
   // some other code
  // enventually call wait(): lock will be release waitin for a notice
  wait();
  // the very access to object
 objectToLock.someMethod(); // this method can be BLOCKING too
}


That is the very most complex definition, while some dev'ers put a synchronized clause without checking for some blocking method.
To be clear, every synchronized clause grant that the encapsuled code is THREAD-SAFE, while it is still possible to crash on a freeze if the lock isn't explicitely notified by a blocking method-call (i.e. (Object).wait(), (Thread)join(), and SOME other).
 Grin
just to know, when/whether I need to synchronize.

I mean the AWT-Event-Thread is fine for most applications, but if

 - I write a console application, everything has to be executed by java.awt.EventQueue.invokeXXX to get rid of synchronization
 - I use another window kit (e.g. the Java GTK wrapper) there might be two different event-threads and I have to synchronize both

Or did I get s.th. wrong?

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #7 - Posted 2007-03-25 14:50:00 »

Hi

We wouldn't need to explicitly do a huge amount more work in some plugins. For example, direct input on windows will return an error code when we try and talk to  the device if it is no longer there, and it's a specific error code saying that the device is gone, so that returned error code could be checked for, and the event fired, all from within which ever thread you used to call poll(). Other platforms are not quite so easy, and neither is detecting new devices, however, I would still expect jinput to use your poll thread to report back to you, even if under the covers, we use our own. The simplest API is a single threaded one, and thats what I still believe we should be exposing to the users. It makes it easier to use JInput as you don't have to worry about anything, you just know that when you call poll, other things under the covers may result in the events happening.

HTH

Endolf

Offline zero

Junior Duke





« Reply #8 - Posted 2007-03-25 16:12:34 »

The simplest API is a single threaded one, and thats what I still believe we should be exposing to the users. It makes it easier to use JInput as you don't have to worry about anything, you just know that when you call poll, other things under the covers may result in the events happening.

I agree 100%.

My point was:
By adding a dispatchEvents() method to the ControllerEnvironment, the API still would be single threaded, since the listener callback would occur in the (single) thread calling this method and doing everything realted to JInput. The only difference/advantage would be, that it takes the controller-added (and optionally controller-removed) events out of the poll methods. Further, IMHO this indicates a single threaded API, but missing does the opposite. Smiley
Note: If the plug-in dowsn't support ControlListeners, as the existing ones, one could rely on a default behavior, e.g. throwing an UnsupportedOperationException.


Btw., another thing (not related to the above):
I don't know about the the native plug-in apis, but I guess its not safe to poll a controller concurrently (from different threads or even VMs). Even if everything is thread-safe, one could miss state changes of 'relative' components. At least such problems occur with the native firewire APIs I worked with. I solved this by introducing some kind of a locking functionality in the API. Am I right that JInput ignores such a potential source of errors?

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #9 - Posted 2007-03-25 19:11:27 »

I *theory* I think most of the plugins it would be ok to call poll from a different thread to the one that initialised the plugin, but i've not tested it Smiley

Yes, you are right that if you call poll from multiple threads, you will miss events on relative devices, once poll has been called, and the event queue read, the event is gone, another thread getting the events will get only those left on the queue. We'll leave the one up to you to solve Smiley

Endolf

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zero

Junior Duke





« Reply #10 - Posted 2007-03-25 19:31:40 »

again, thanks a lot for all the information endolf, really helpful Smiley



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 (41 views)
2014-10-17 03:59:02

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

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

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

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

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

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

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

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

BurntPizza (80 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!