I am designing a small threading framework, and i’d like that threading framework to be as transparent as possible to the final code, in such a way that it barely affects the syntax of linear code. I’ve thought out most of the pieces, yet something is giving me an itch: How to define a parameter so function calls are NOT resolved until i’ve succesfully switched out their context into a new thread?
The idea:
var myTask = new Transaction();
myTask < xyz.abc();
myTask < xyz.def();
...some more code...
var result = waitfornext myTask;
In essence, myTask would grab the abc() and def() calls and pipeline them into a Thread, then the waitfor operator would block until myTask’s pipeline has finished and code that depended on abc() and def() can continue. In a manner of speaking this IS .Net’s await/async model, but i’d like to re-do it my own way so it can be used across all .Net versions, and possibly be ported to Java/XYZ languages.
The problem:
The abc() and def() calls would be evaluated by the compiler BEFORE feeding their return values to the < operator, what i really want though, is to be able to have those function calls fed to the operator so i can defer execution of them until the pipeline thread is ready to do so.
The rationale:
Unlike the async/await model, you wouldn’t have to modify your methods so they can be async’ed, and you could use any method with the transactioned methods anyway. Another advantage would be that with erasing a couple lines your code would be back to being linear (Not that the async model doesn’t have this advantage, but it’s worth mentioning it anyways)
Any ideas?
Instead of passing
xyz.abc()as the parameter, which will be evaluated then and there, instead pass something that can becomexyz.abc(), and modify the target method to do the ‘becoming’:Change
To