Menu
▾
▴
rails-devel
|
From: Frederick W. <fre...@go...> - 2012-02-15 18:58:26
|
In RunGame, I've found the following comment: "We have to run loadGame on an AWT EventQueue to make sure that NDC will properly initialize game key so that GameManager instance can be properly queried for. This is a consequence of NDC abuse." New games are also initialized within EDT since this is triggered by the button pressed event. So my question to Erik/Stefan/Brett: What is the goal of (ab)using the EDT? Is it that only one game may be started at the same time? -- Frederick |
|
From: Erik V. <eri...@xs...> - 2012-02-15 23:24:17
|
No. The goal is to provide access to the current GameManager for objects that don't have a reference to it: via a thread property. That is what NDC provides. Originally GameManager was a singleton, and in those times it was easy. But at some point we decided that we should be prepared for multiple games running in the same JVM, and NDC was the only mechanism I knew about that could help me out to identify which GM any object would belong to. Currently the implementation is still rudimentary, as the GM key given to NDC is fixed. But in a multi-game server, that key should be derivable, for instance from the identity of the stream over which an incoming player action would arrive. I hope this is a bit clear... Erik. > -----Original Message----- > From: Frederick Weld [mailto:fre...@go...] > Sent: Wednesday, February 15, 2012 7:58 PM > To: Development list for Rails: an 18xx game > Subject: [Rails-devel] Game Initialization within the EDT / AWT EventQueue > > In RunGame, I've found the following comment: > "We have to run loadGame on an AWT EventQueue to make sure that NDC > will properly initialize game key so that GameManager instance can be > properly queried for. This is a consequence of NDC abuse." > > New games are also initialized within EDT since this is triggered by the button > pressed event. > > So my question to Erik/Stefan/Brett: > What is the goal of (ab)using the EDT? Is it that only one game may be started > at the same time? > > -- Frederick > > ---------------------------------------------------------------------------- -- > Virtualization & Cloud Management Using Capacity Planning Cloud computing > makes use of virtualization - but cloud computing also focuses on allowing > computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Frederick W. <fre...@go...> - 2012-02-16 06:50:38
|
Erik: Thanks for the clarification. As far as I have understood, the current concept is as follows: - assign a game manager key to a thread (using NDC push) - return game manager instances based on current thread (using NDC peek) - currently, this works as it is assumed that rails is only run in EDT - in the future, proxy game managers apply this concept by running in their dedicated thread I perceive the following shortcoming: The concept stipulates that game initialization is performed within EDT - hampering potential for parallelization - rendering visualization of initialization process impossible Based on that I would propose altering the concept as follows: - remove game key and NDC push for the local game manager (former EDT instance) - in the getGameManager, assume that the local game manager is to be returned if peek returns that no NDC push has taken place for this thread - for game manager service instances, the current concept of identifying game managers by stream threads (or similar) is applicalbe as in the original concept (no change here) This altered concept doesn't have any disadvantage over the original one and would enable us to put local game initialization outside of the EDT. What's your take on this? Is there anything else to be considered? Otherwise, I would try to adopt the altered concept accordingly. -- Frederick |
|
From: Erik V. <eri...@xs...> - 2012-02-16 09:38:26
|
Frederick, What does EDT mean? > - in the getGameManager, assume that the local game manager is to be > returned But which GameManager is "the local game manager" in a (future) multi-game server? This idea doesn't sound like a final solution. In fact, I was thinking in the same direction that Stefan is now taking: put all Rails objects in one tree. Erik. > -----Original Message----- > From: Frederick Weld [mailto:fre...@go...] > Sent: Thursday, February 16, 2012 7:50 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Game Initialization within the EDT / AWT > EventQueue > > Erik: > Thanks for the clarification. > > As far as I have understood, the current concept is as follows: > - assign a game manager key to a thread (using NDC push) > - return game manager instances based on current thread (using NDC peek) > - currently, this works as it is assumed that rails is only run in EDT > - in the future, proxy game managers apply this concept by running in their > dedicated thread > > I perceive the following shortcoming: > The concept stipulates that game initialization is performed within EDT > - hampering potential for parallelization > - rendering visualization of initialization process impossible > > Based on that I would propose altering the concept as follows: > - remove game key and NDC push for the local game manager (former EDT > instance) > - in the getGameManager, assume that the local game manager is to be > returned if peek returns that no NDC push has taken place for this thread > - for game manager service instances, the current concept of identifying > game managers by stream threads (or similar) is applicalbe as in the original > concept (no change here) > > This altered concept doesn't have any disadvantage over the original one and > would enable us to put local game initialization outside of the EDT. > > What's your take on this? > Is there anything else to be considered? > Otherwise, I would try to adopt the altered concept accordingly. > > -- Frederick > > ---------------------------------------------------------------------------- -- > Virtualization & Cloud Management Using Capacity Planning Cloud computing > makes use of virtualization - but cloud computing also focuses on allowing > computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Frederick W. <fre...@go...> - 2012-02-16 06:57:34
|
Only now, I've seen Stefan's response regarding the situation in Rails 2.0 Erik/Stefan: Assuming that rails 2.0 preceeds the development of distributed rails, this would mean that I could drop the current mechanism completely for 1.x - thus, returning to the singleton pattern. Would that be ok for you? -- Frederick |
|
From: Stefan F. <ste...@we...> - 2012-02-16 06:32:48
|
Some more details on that: The method Erik refers to below is getInstance() of GameManager. This method will only work from the thread that created the GameManager instance. So be aware that in essence any call to the Rails main core methods can fail if done outside the main thread. This is one of the reasons why the RevenueAdapter object is created and evaluated inside the main thread so that the revenue calculation is isolated from any calls to the core Rails engine and can run in a separate thread. This mechanism will be dropped moving onto Rails 2.0 and is replaced by a thread-safe mechanism (essentially be giving all items access to a GameManager equivalent by placing all Rails objects into a tree hierarchy). Stefan On 02/16/2012 12:24 AM, Erik Vos wrote: > No. The goal is to provide access to the current GameManager for objects > that don't have a reference to it: via a thread property. That is what NDC > provides. > > Originally GameManager was a singleton, and in those times it was easy. > But at some point we decided that we should be prepared for multiple games > running in the same JVM, and NDC was the only mechanism I knew about that > could help me out to identify which GM any object would belong to. > > Currently the implementation is still rudimentary, as the GM key given to > NDC is fixed. But in a multi-game server, that key should be derivable, for > instance from the identity of the stream over which an incoming player > action would arrive. > > I hope this is a bit clear... > > Erik. > >> -----Original Message----- >> From: Frederick Weld [mailto:fre...@go...] >> Sent: Wednesday, February 15, 2012 7:58 PM >> To: Development list for Rails: an 18xx game >> Subject: [Rails-devel] Game Initialization within the EDT / AWT EventQueue >> >> In RunGame, I've found the following comment: >> "We have to run loadGame on an AWT EventQueue to make sure that NDC >> will properly initialize game key so that GameManager instance can be >> properly queried for. This is a consequence of NDC abuse." >> >> New games are also initialized within EDT since this is triggered by the > button >> pressed event. >> >> So my question to Erik/Stefan/Brett: >> What is the goal of (ab)using the EDT? Is it that only one game may be > started >> at the same time? >> >> -- Frederick >> >> > ---------------------------------------------------------------------------- > -- >> Virtualization& Cloud Management Using Capacity Planning Cloud computing >> makes use of virtualization - but cloud computing also focuses on allowing >> computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2012-02-16 09:45:43
|
> Erik/Stefan: > Assuming that rails 2.0 preceeds the development of distributed rails, this > would mean that I could drop the current mechanism completely for 1.x - > thus, returning to the singleton pattern. > > Would that be ok for you? Maybe I have missed something, but is there an actual bug that needs be fixed? Personally, I would prefer to keep future developments open until it's clear where Stefan will come up with. Erik. |
|
From: Frederick W. <fre...@go...> - 2012-02-16 10:51:36
|
Erik: EDT is the Swing Event Dispatcher Thread which handles the AWT queue (as far as I know). Currently, I'm working on speeding up and visualizing the game initialization process (ie., after leaving the game setup and before the game windows are ready). This process takes about 20secs for loading an end game on my computer. Both goals rely on freeing up the EDT for his core tasks - hence my request to alter the current concept. Given this motivation, what's your opinion on this? -- Frederick |
|
From: Erik V. <eri...@xs...> - 2012-02-16 12:15:01
|
Well, go ahead, then. The idea of a multi-game server is a long shot anyway. Erik. > -----Original Message----- > From: Frederick Weld [mailto:fre...@go...] > Sent: Thursday, February 16, 2012 11:51 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Game Initialization within the EDT / AWT > EventQueue > > Erik: > EDT is the Swing Event Dispatcher Thread which handles the AWT queue (as > far as I know). > > Currently, I'm working on speeding up and visualizing the game initialization > process (ie., after leaving the game setup and before the game windows are > ready). This process takes about 20secs for loading an end game on my > computer. > Both goals rely on freeing up the EDT for his core tasks - hence my request to > alter the current concept. > > Given this motivation, what's your opinion on this? > > -- Frederick > > ---------------------------------------------------------------------------- -- > Virtualization & Cloud Management Using Capacity Planning Cloud computing > makes use of virtualization - but cloud computing also focuses on allowing > computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Frederick W. <fre...@go...> - 2012-02-17 06:17:58
|
Erik: Ok. I've only removed the NDC push/peek. The rest of the related code and the comment (which I amended) are still in place in case we want to revert back. -- Frederick |
|
From: Stefan F. <ste...@we...> - 2012-02-17 16:29:03
|
Frederick, I was under impression that it is mainly the UI startup (loading all tiles etc.) that impacts the startup performance. What I have not investigated yet is whether the UI objects get created before or after the game has been processed until the end of the action stack. Processing the game itself is pretty fast, as the automated testing proves (which runs on my system 8.7 seconds for 22 games). Have you already run a profiler? Stefan On 02/16/2012 11:51 AM, Frederick Weld wrote: > Erik: > EDT is the Swing Event Dispatcher Thread which handles the AWT queue > (as far as I know). > > Currently, I'm working on speeding up and visualizing the game > initialization process (ie., after leaving the game setup and before > the game windows are ready). This process takes about 20secs for > loading an end game on my computer. > Both goals rely on freeing up the EDT for his core tasks - hence my > request to alter the current concept. > > Given this motivation, what's your opinion on this? > > -- Frederick > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Frederick W. <fre...@go...> - 2012-02-17 17:03:11
|
Stefan: My perception was not based on a in-depth profiler analysis but on the observation that the quad core's load was only at 50% since the initialization code didn't allow for any parallelization (except for the included libs like the svg renderer). After putting initialization into a non-EDT, the load gets close to 100% (at some portion of times - ie., when EDT rendering and framework initialization occur in parallel). But ok, even if only a few seconds are gained at the end, we will have at least a nice visualization of the startup, including that all windows become available at once (the visualization having been my main goal). -- Frederick |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X