Difference between revisions of "User talk:PiRocks"
(agreed) |
(Comments from Fnl about the ThreadGroup hack and using more threads in attempt to cheat.) |
||
| Line 15: | Line 15: | ||
Greetings and Welcome to the Robowiki, good luck with your bots. I'm curious though... you say "work-a-round method to create more threads". What do you mean precisely by that? To me that sounds like a security bug in the new version in 1.7.2.1 Beta --[[User:Rednaxela|Rednaxela]] 04:19, 24 June 2010 (UTC) | Greetings and Welcome to the Robowiki, good luck with your bots. I'm curious though... you say "work-a-round method to create more threads". What do you mean precisely by that? To me that sounds like a security bug in the new version in 1.7.2.1 Beta --[[User:Rednaxela|Rednaxela]] 04:19, 24 June 2010 (UTC) | ||
| − | My work-a-round mechanism is to create a new ThreadGroup that is Inserted to the main ThreadGroup. Then all threads inserted into this ThreadGroup. All the threads in this group will not be registered by calling enumerate on my robot's ThreadGroup, so it is not Disabled for having too many threads. [[User:PiRocks|PiRocks]] 13:12, 24 June 2010 (UTC)PiRocks | + | My work-a-round mechanism is to create a new ThreadGroup that is Inserted to the main ThreadGroup. Then all threads inserted into this ThreadGroup. All the threads in this group will not be registered by calling enumerate on my robot's ThreadGroup, so it is not Disabled for having too many threads. [[User:PiRocks|PiRocks]] 13:12, 24 June 2010 (UTC)PiRocks. |
| + | : Nice work! :-) I didn't realize that, so I will give it a try and of course check if the 1.7.2.0 and earlier versions has this problem. I will of course fix this security flaw ASAP before the final version of 1.7.2.1. Keep on hacking. It's a good way to get the security tested in depth. :-) --[[User:FlemmingLarsen|Fnl]] 17:16, 25 June 2010 (UTC) | ||
I believe that you are creating more than five threads? Just a note though, while it is not forbidden, using thread in RoboRumble-participated robot is [[oldwiki:MultiThreading/Ethics|commonly consider as a time-cheater]]. Since each robot run in its own thread in a sandboxed, time limited environment, and the thread controlling is done entirely by the OS, using thread will steal other robot processing time. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:54, 24 June 2010 (UTC) | I believe that you are creating more than five threads? Just a note though, while it is not forbidden, using thread in RoboRumble-participated robot is [[oldwiki:MultiThreading/Ethics|commonly consider as a time-cheater]]. Since each robot run in its own thread in a sandboxed, time limited environment, and the thread controlling is done entirely by the OS, using thread will steal other robot processing time. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:54, 24 June 2010 (UTC) | ||
: Not only that, it is my wonder why you would need so much processing time, or so many parallel processes. — <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 14:48, 24 June 2010 (UTC) | : Not only that, it is my wonder why you would need so much processing time, or so many parallel processes. — <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 14:48, 24 June 2010 (UTC) | ||
| + | : I have considered removing the option to create more thread in Robocode. However, this will brake backwards compatibility. Another option might be to monitor the total CPU time used by the robot by monitoring the CPU usage of all threads of a robot. If the CPU usage is bigger than our CPU constant, then either the robot will be disabled or the thread priorities will be lowered. --[[User:FlemmingLarsen|Fnl]] 17:16, 25 June 2010 (UTC) | ||
Revision as of 18:16, 25 June 2010
|
Welcome! Hello, PiRocks, and welcome to RoboWiki! This place contains a wealth information about Robocode, from basic to more advanced. I hope you enjoy creating robots and being a robocoder! If you are posting a comment on this wiki, please sign your messages using four tildes (--~~~~); this will automatically insert your username and the date stamp. If you are not familiar with MediaWiki, these links might help you out:
If you need help, check out the frequently asked questions or ask it on this page. Again, welcome! —— RoboWiki Administrators |
Greetings and Welcome to the Robowiki, good luck with your bots. I'm curious though... you say "work-a-round method to create more threads". What do you mean precisely by that? To me that sounds like a security bug in the new version in 1.7.2.1 Beta --Rednaxela 04:19, 24 June 2010 (UTC)
My work-a-round mechanism is to create a new ThreadGroup that is Inserted to the main ThreadGroup. Then all threads inserted into this ThreadGroup. All the threads in this group will not be registered by calling enumerate on my robot's ThreadGroup, so it is not Disabled for having too many threads. PiRocks 13:12, 24 June 2010 (UTC)PiRocks.
- Nice work! :-) I didn't realize that, so I will give it a try and of course check if the 1.7.2.0 and earlier versions has this problem. I will of course fix this security flaw ASAP before the final version of 1.7.2.1. Keep on hacking. It's a good way to get the security tested in depth. :-) --Fnl 17:16, 25 June 2010 (UTC)
I believe that you are creating more than five threads? Just a note though, while it is not forbidden, using thread in RoboRumble-participated robot is commonly consider as a time-cheater. Since each robot run in its own thread in a sandboxed, time limited environment, and the thread controlling is done entirely by the OS, using thread will steal other robot processing time. --Nat Pavasant 12:54, 24 June 2010 (UTC)
- Not only that, it is my wonder why you would need so much processing time, or so many parallel processes. — Chase-san 14:48, 24 June 2010 (UTC)
- I have considered removing the option to create more thread in Robocode. However, this will brake backwards compatibility. Another option might be to monitor the total CPU time used by the robot by monitoring the CPU usage of all threads of a robot. If the CPU usage is bigger than our CPU constant, then either the robot will be disabled or the thread priorities will be lowered. --Fnl 17:16, 25 June 2010 (UTC)
