Difference between revisions of "Creating Multithreaded Skyrim Mods"

Jump to navigation Jump to search

Creating Multithreaded Skyrim Mods (edit)

Revision as of 16:24, 22 January 2015

800 bytes added ,  16:24, 22 January 2015
no edit summary
imported>Chesko
imported>Chesko
Line 159: Line 159:
* '''Control who can access results:''' The result can only be retrieved by someone who knows the Future of your thread. You have control over who can retrieve your results.
* '''Control who can access results:''' The result can only be retrieved by someone who knows the Future of your thread. You have control over who can retrieve your results.
* '''Control when results are retrieved:''' The result is only retrieved when you ask for it. This is important when you need to retrieve results in a particular order.
* '''Control when results are retrieved:''' The result is only retrieved when you ask for it. This is important when you need to retrieve results in a particular order.
* '''Easier to follow:''' A thread can be started and results retrieved all within the same function; your code does not have to "jump around" as much as it does in the Callback pattern.
* '''Easier to trace execution order:''' A thread can be started and results retrieved all within the same function; your code does not have to "jump around" as much as it does in the Callback pattern.
* '''Abstracts away "locks":''' With Futures, we don't have to worry about two threads accidentally manipulating the same variable in the wrong order because one finished faster or slower than the other. We just request our results from our futures in the order that we want them.
* '''Abstracts away "locks":''' With Futures, we don't have to worry about two threads accidentally manipulating the same variable in the wrong order because one finished faster or slower than the other. We just request our results from our futures in the order that we want them.
* '''Requires less state management:''' Managing the state of your script is almost as simple as when you wrote scripts in a single thread calling functions directly.
* '''Requires less state management:''' Managing the state of your script is almost as simple as when you wrote scripts in a single thread calling functions directly.


==== Futures Cons ====
==== Futures Cons ====
* '''Harder to understand:''' Implementing a Future-based approach requires learning several new concepts.
* '''Harder to implement:''' There are more pieces involved in setting up a Future-based approach.
* '''More overhead (slower):''' A Future-based approach can be slower than using a Callback approach, due to the fact that Futures are ObjectReferences and must be created and destroyed when a thread runs and data is read.
* '''Results availability and delays:''' If you call <code>get_result()</code> on a Future, and the result is not yet ready, the script will wait until it is, and then return the result. You are at the mercy of the thread to return a value to the future until you can continue. For some applications, this may be considered a pro.
* '''Results availability and delays:''' If you call <code>get_result()</code> on a Future, and the result is not yet ready, the script will wait until it is, and then return the result. You are at the mercy of the thread to return a value to the future until you can continue. For some applications, this may be considered a pro.
* '''Harder to make results public:''' If you have many intended consumers of your thread's results (many scripts, or even scripts on other people's mods), using Futures may be burdensome for getting your results to everyone who needs them.
* '''Harder to make results public:''' If you have many intended consumers of your thread's results (many scripts, or even scripts on other people's mods), using Futures may be burdensome for getting your results to everyone who needs them.
Line 205: Line 208:
* '''Results received without delays:''' Unlike Futures, you do not have to block your script pending results being available. Just register for the appropriate event and react to it.
* '''Results received without delays:''' Unlike Futures, you do not have to block your script pending results being available. Just register for the appropriate event and react to it.
* '''No polling:''' You no longer have to potentially poll for whether or not your results are ready.
* '''No polling:''' You no longer have to potentially poll for whether or not your results are ready.
* '''Easier to understand:''' The concepts in a Callback pattern are nothing new to anyone who knows how to use Mod Events.
* '''Easier to implement:''' Their are comparatively fewer things to deal with when using a Callback pattern.
* '''Less overhead (faster):''' Using a callback pattern can be a bit faster than a Future-based approach.


==== Callback Cons ====
==== Callback Cons ====
* '''...Anyone can access results:''' You have no control over who is able to consume your results.
* '''...Anyone can access results:''' You have no control over who is able to consume your results.
* '''No control when results are retrieved:''' You have no control over when a result will be retrieved, or in what order. You must be able to react to the result events that are raised, and you must assume that threads can finish in any order.
* '''No control when results are retrieved:''' You have no control over when a result will be retrieved, or in what order. You must be able to react to the result events that are raised, and you must assume that threads can finish in any order.
* '''More difficult to follow:''' A callback pattern can make the script flow more difficult to follow and debug, since the function where a thread is started and the event that it returns results to will be in two (or more) different places.
* '''More difficult to trace execution order:''' A callback pattern can make the script flow more difficult to follow and debug, since the function where a thread is started and the event that it returns results to will be in two (or more) different places.
* '''Locks required:''' Locks are required if you have two threads that may write to the same variable.
* '''Locks required:''' Locks are required if you have two threads that may write to the same variable.
* '''Requires more state management:''' You can receive result callbacks at any time, which may make it necessary for you to re-evaluate the script's current state each time you receive one, depending on your application.
* '''Requires more state management:''' You can receive result callbacks at any time, which may make it necessary for you to re-evaluate the script's current state each time you receive one, depending on your application.
Anonymous user
Retrieved from "https://ck.uesp.net/wiki/Special:MobileDiff/8831"

Navigation menu