Showing how you can extend the PPL to get the true power of asynchronous task execution.

-
Showing how you can extend the PPL to get the true power of asynchronous task execution.
http://delphisorcery.blogspot.com/2015/02/extending-parallel-programming-library.html

Comments

  1. Jeroen Wiert PluimersFebruary 21, 2015 at 8:01 AM

    the dreaded OnClick programming...

    ReplyDelete
  2. Asbjørn HeidFebruary 22, 2015 at 6:17 AM

    I was wondering why they hadn't added continuation. Such a basic thing.

    ReplyDelete
  3. Jeroen Wiert PluimersFebruary 22, 2015 at 6:40 AM

    Asbjørn Heid indeed. Though some disagree when you state PPL is incomplete.

    ReplyDelete
  4. Markus JoosFebruary 23, 2015 at 3:47 AM

    Jeroen Wiert Pluimers
    Surely it is a matter of the definition if one considers the PPL as incomplete. But compared to other libraries like the TPL it is incomplete. Fortunately it is relatively easy to extend it, as Stefan has just demonstrated.

    ReplyDelete
  5. Asbjørn HeidFebruary 23, 2015 at 3:50 AM

    Markus Joos The problem is fragmentation for library writers.

    ReplyDelete
  6. Markus JoosFebruary 24, 2015 at 3:11 AM

    Stefan, I took the liberty to extend / change your code a little bit: http://pastebin.com/Tf80DPH0
    1) I introduced a new method ContinueWithGui. This makes your GExperts macro superfluous (well at least for this case)
    2) I changed the code to assign the inner exception object to the exposed ExceptionObject rather than the Aggregated Exception

    ReplyDelete
  7. Stefan GlienkeFebruary 24, 2015 at 3:18 AM

    Markus Joos I think ContinueWithGUI is broken and will most likely return nil. I am also not sure if the entire ContinueWith should be put into TThread.Queue.

    I would rather make an InternalContinueWith that gets passed a flag if queue or not and then wrap the continuationAction call into the TThread.Queue.

    Also your change to the exception causes a memory leak.

    ReplyDelete
  8. Markus JoosFebruary 24, 2015 at 3:39 AM

    Stefan Glienke
    Theoretically you are right and the result should be nil in most cases. In my tests however the result wasn't nil. But you are right, so here is take 2:
    http://pastebin.com/jtS0q6P8
    I also had some parameters switched in my first version, so it actually didn't compile

    ReplyDelete
  9. Markus JoosFebruary 24, 2015 at 3:46 AM

    Stefan Glienke
    I had also been working on a version with conditional continuation (faulted, completed etc) which turned out to be somewhat more complicated. But I am not sure if this would be useful at all to begin with.

    ReplyDelete
  10. Stefan GlienkeFebruary 24, 2015 at 3:57 AM

    Markus Joos Copy and pasting the entire method instead of refactoring is almost an insult. ;p
    I also fixed your memleak with the exception: http://pastebin.com/Fp53qjUG

    ReplyDelete
  11. Markus JoosFebruary 24, 2015 at 4:47 AM

    Stefan Glienke
    You are absolutely right! I should definitely not publicly post quick and dirty code.
    What do you think of a conditional continuation? Would it be worth investigating?

    ReplyDelete
  12. Stefan GlienkeFebruary 24, 2015 at 5:26 AM

    Markus Joos Isn't that conditional continuation already? See http://dotnetcodr.com/2014/03/14/continuation-tasks-in-net-tpl-make-continuation-conditional/

    ReplyDelete
  13. Markus JoosFebruary 24, 2015 at 5:40 AM

    Stefan Glienke
    Now I see. In this sense, yes it is. But what if I want to conditionally want to continue with task 1 if main task faulted or task 2 if main task completed ?

    ReplyDelete
  14. Markus JoosFebruary 24, 2015 at 5:46 AM

    Stefan Glienke
    Take 4 (needs cleanup. just to demonstrate what I mean)
    http://pastebin.com/9c00K5HZ
    usage:
    http://pastebin.com/h1KmZNEk

    ReplyDelete
  15. Stefan GlienkeFebruary 24, 2015 at 6:48 AM

    That's  nonsense. If you want to continue in all cases then write an overload for ContinueWith (https://msdn.microsoft.com/de-de/library/dd270696(v=vs.110).aspx) that does not take a TTaskContinuationOptions and check ITaskEx.Status in the continuationAction. TTaskContinuationOptions are designed in a way that they don't need to be combined as set.

    ReplyDelete
  16. Markus JoosFebruary 24, 2015 at 6:54 AM

    Stefan Glienke
    In that specific case, you are right. But what if I want to continue on e.g. fault and cancel bot not on completed? There is no point in invoking the task for completed if in the task I decide to ignore it.
    And btw IMHO having the condition(s) as the first parameter is more readable than having them at the end (as in the TPL)

    ReplyDelete
  17. Stefan GlienkeFebruary 24, 2015 at 7:36 AM

    Markus Joos Then you call it with NotOnCompleted.
    I disagree about the order because personally I prefer to keep the index of the arguments the same across the overloads as much as possible.
    But as this post was just to illustrate what can be done you are free to write whatever code you want :)

    ReplyDelete
  18. Markus JoosFebruary 24, 2015 at 7:38 AM

    Stefan Glienke
    Damn, you got me ;-) But I still think that the condition at the beginning is superior.
    Obviously they should be the same across all overloads.

    ReplyDelete

Post a Comment