Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| en:toolworks:docs:apparatus:operating [2021/08/28 21:15] – [Concurrency] vladius | en:toolworks:docs:apparatus:operating [2023/01/14 10:13] (current) – vladius | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Operating ====== | ====== Operating ====== | ||
| - | The newer and more robust way of processing | + | The newer and more robust way of handle |
| ===== C++ Workflow ===== | ===== C++ Workflow ===== | ||
| Line 7: | Line 7: | ||
| ==== Using a Lambda ==== | ==== Using a Lambda ==== | ||
| - | You can easily operate on your chain via a C++ lambda and this is how you do it: | + | You can easily operate on your chain via a [[cpp> |
| <code cpp> | <code cpp> | ||
| - | Chain-> | + | Chain-> |
| { | { | ||
| ... | ... | ||
| Line 15: | Line 15: | ||
| </ | </ | ||
| - | The type of cursor here must match the type of the chain used. | ||
| Note that you're not allowed to acquire a reference to the trait while processing a non-solid chain, only its copy. | Note that you're not allowed to acquire a reference to the trait while processing a non-solid chain, only its copy. | ||
| So in order to operate on a solid chain, you could do something like this: | So in order to operate on a solid chain, you could do something like this: | ||
| <code cpp> | <code cpp> | ||
| - | SolidChain-> | + | SolidChain-> |
| { | { | ||
| ... | ... | ||
| Line 36: | Line 35: | ||
| <code cpp> | <code cpp> | ||
| - | SolidChain-> | + | SolidChain-> |
| { | { | ||
| ... | ... | ||
| Line 44: | Line 43: | ||
| The second parameter helps to also limit the number of tasks. If there are too little slots | The second parameter helps to also limit the number of tasks. If there are too little slots | ||
| available, excessive tasks not needed for that quantity won't be queued at all. | available, excessive tasks not needed for that quantity won't be queued at all. | ||
| + | |||
| + | ==== Dependency Injection ==== | ||
| + | |||
| + | One great thing about operating is that the function arguments are actually resolved | ||
| + | and delivered automatically to your logic. For example, if you also modify the currently | ||
| + | iterated subject, just specify the Subject handle in the very declaration of the routine:< | ||
| + | Chain-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | This, of course, has to match the solidity of the chain. So for a solid chain this would be:<code cpp> | ||
| + | SolidChain-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | You can actually ask for different contextual information within the loop. For example:< | ||
| + | Chain-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | ==== Current Iteration Index ==== | ||
| + | |||
| + | Just in case you need to know the number of the current iterated Slot (i.e. Subject' | ||
| + | SolidChain-> | ||
| + | { | ||
| + | Placement.Number = Cursor.GetChainSlotIndex(); | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | ==== Stopping ==== | ||
| + | |||
| + | While conceptually not very clean it is sometime useful to stop the actual processing (iterating) of the chain | ||
| + | prematurely, | ||
| + | |||
| + | For example:< | ||
| + | int32 Counter = 0; | ||
| + | Chain-> | ||
| + | { | ||
| + | if (Counter > 100) | ||
| + | { | ||
| + | Chain-> | ||
| + | // Return explicitly, so the counter doesn' | ||
| + | return; | ||
| + | } | ||
| + | Counter += Trait.Value; | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | ==== Direct Mechanism Operating ==== | ||
| + | |||
| + | The Operating simplification goes as far as actually Operating on a Mechanism directly, like so:<code cpp> | ||
| + | Mechanism-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | This way the [[en: | ||
| + | |||
| + | You can of course supply the Filter specification explicitly, overriding it. | ||
| + | |||
| + | So for example, if you want to specify an additional [[en: | ||
| + | Mechanism-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | The direct Operating mode is smart enough to deduce the type of the Chain used within the Operating process, so if you specify a reference to a Trait and/or a Solid Subject handle in your arguments list, the technique will essentially produce a [[en: | ||
| + | Mechanism-> | ||
| + | { | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | You can still specify the Chain type explicitly as a first template argument to a method:< | ||
| + | Mechanism-> | ||
| + | { | ||
| + | // You logic within Solid semantics: | ||
| + | ... | ||
| + | }); | ||
| + | </ | ||
| + | |||
| + | Concurrency variants are also provided by the direct interface:< | ||
| + | Mechanism-> | ||
| + | { | ||
| + | ... | ||
| + | }, /*Maximum number of threads=*/ | ||
| + | </ | ||