Changes in Parallel Library

[Mark NZ 0]

We see issues with TTask's not starting or slow to start with Delphi that still exist in 10.3.2, this has been happening now for several years across different versions!

The problems can be intermittent but frequent.  My boss had no issues with TTask for quite some time while for me it was VERY frequently unusable - same code running.  He's now seen on his machine the issues I was running into.

 

Here are links to a few logged issues, in 23466 there are comments from Embarcadero that they are aware of the issues and there are no resources currently dedicated to it.  There is an 'EPIC' assigned for R104 so maybe it'll be better by the end of next year.

 

https://quality.embarcadero.com/browse/RSP-23466
https://quality.embarcadero.com/browse/RSP-12557 (closed as works as expected, I believe behaviour is wrong)

https://quality.embarcadero.com/browse/RSP-15233

https://quality.embarcadero.com/browse/RSP-24103

https://quality.embarcadero.com/browse/RSP-23874

 

 

[Remy Lebeau 1393]

2 hours ago, Mark NZ said:

We see issues with TTask's not starting or slow to start with Delphi that still exist in 10.3.2, this has been happening now for several years across different versions!

I have seen many people report many problems with the PPL over the years.  And for that reason, I REFUSE to ever use the PPL at all.  I don't trust it.  It hasn't worked right since day 1, and Embarcadero just can't seem to get it right.  I prefer to stay in control of my own threads.

Edited October 1, 2019 by Remy Lebeau

[Larry Hengen 39]

I agree with that assessment. I would use the OmniThread Library before the PPL or roll my own threads.

[Der schöne Günther 316]

https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?

[Stefan Glienke 2002]

1 hour ago, Der schöne Günther said:

https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?

I doubted that already

[Primož Gabrijelčič 223]

1 hour ago, Der schöne Günther said:

https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?

"This also appears to affect OmiThreadLibrary" without any accompanying code does not mean anything. It was probably a moon phase, or Mercury in retrograde, not OTL.

[Der schöne Günther 316]

Good to know, thank you both.

 

Sad to hear nobody really believes in Delphis PPL. Our main product has a weird mix of OmniThreadLibrary and Delphis PPL, I think if we ever upgrade beyond 10.0 Seattle, then we should probably get rid of Delphis PPL as well... 😒

 

 

[Uwe Raabe 2057]

I would prefer when PPL would be fixed and stabilized instead of not being used at all. There is a couple of functionality in Delphi that relies on PPL and that would need to be reinvented where another external library is used.

 

The lack of manpower dedicated to this part of the RTL (and a lot of others) is a real drawback. I wish Embarcadero would allow more participation from the community or at least all the MVPs that already offered their help in these areas. Another option would be to open source the standard libraries and accept pull requests, but that seems to be only at the edge of their radar - if at all.

[Dalija Prasnikar 1396]

Having good core libraries is essential. Otherwise everybody keeps rolling their own. At the end if you have to use multiple libraries they tend to be incompatible and have duplicated code.

 

So +1000 for having things fixed at the root. Same goes for IDE. Every time some basic functionality is either broken or missing, we need to push harder to have that functionality fixed without relying of various plugins.

 

Having said that, I have utmost respect for all people devoting their time creating those valuable tools and libraries.

[Stefan Glienke 2002]

41 minutes ago, Uwe Raabe said:

I would prefer when PPL would be fixed and stabilized instead of not being used at all.

We have a catch 22 here. If stuff does not work I don't use it - especially if it tries to solve a task that has already been solved years ago.

So if people don't use it less people are affected by bugs and less likely it is they get fixed - however even when issues are being reported by many people it takes time to fix them and only with an upgrade you get those fixes.

With a library like OTL you don't need to upgrade your entire IDE to get some bugfix.

 

This is the fundamental flaw you have when IDE, compiler and runtime are so tightly coupled that they cannot be upgraded individually. That plus a lack of quality control.

[John Kouraklis 94]

My experience is the same as @pyscripter's

 

I use PPL quite extensively and any bottlenecks appear with programming logic and some other tasks (with server requests the main one)

 

The major problem I have come across is that WaitForAll does not behave as expected in many cases but I found that rewriting the tasks in ITasks can fix this

[John Kouraklis 94]

And what keeps me away from OTL is cross-platform implementation. These days I only touch FMX apps

[Uwe Raabe 2057]

3 hours ago, Stefan Glienke said:

With a library like OTL you don't need to upgrade your entire IDE to get some bugfix.

I understand that. On the other hand you get a problem with other parts of the RTL (f.i. THTTPClient) which obviously cannot make use of OTL to achieve some multi-threading features like async execution. If OTL is the choice for multi-threading one has to write its own async functionality for these parts based on OTL, which might turn out pretty time consuming (and also error prone). A reliable RTL with all of its parts working together out of the box would beat any manually assembled set of third party libs by magnitude.

 

I fully agree with you regarding the lack of  quality control, though.

 

[Stefan Glienke 2002]

55 minutes ago, Uwe Raabe said:

I understand that. On the other hand you get a problem with other parts of the RTL (f.i. THTTPClient) which obviously cannot make use of OTL to achieve some multi-threading features like async execution.

Which also was an RTL thing that was very late to the party and thus has to compete with solutions that already existed before it.

And yes if there have been other solutions in need of some multi-threading they either had to roll their own or only be compatible or rely on other third party components themselves which they usually rather refrain from.

 

So what we have achieved in the past few years in the RTL is closing the gap on the feature matrix to give the impression that for nowadays standard usecases like http, json or easy parallel processing you don't need any specific third party components or libraries but once you start using them you quickly run into numerous issues that range from "little annoying" to "absolute showstopper". And often fixes either take multiple iterations or major versions and range from "now you broke something else" to "dirty hack because of keeping broken behavior because of backwards compatibility"

 

Even using the smallest RTL feature these days causes me to look into the implementation before recommending it to my coworkers, telling them to stop using them or not giving green light to upgrade the newest Delphi version (RSP-19439 for example) - sad but true.

 

If it weren't for licensing reasons and the impossibility to fix many bugs that interest me by just recompiling the RTL (depending on what units you change) I would have started an "enhanced RTL" project already to fix the most annoying issues (like the ridiculous code bloat caused by System.Generics.Collections/Defaults and many other annoyances). At least the latter was solved by banishing those units from our code entirely and exclusively using spring4d collections. Using any third party code and the RTL and VCL itself though still is affected by that.

Edited October 2, 2019 by Stefan Glienke

[Esteban Pacheco 16]

Windows -> OTL

Cross-platform -> ??? 

 

I dont think OTL in cross-platform mode is a possibility in the near short-mid future, so PPL must do for any FMX development.  Hopefully they will keep improving it, cause we dont have a choice unless we want to jump into using our own implementations and I dont trust myself with that. 🙂

 

 

 

[John Kouraklis 94]

Recently I added code to this amazing library https://github.com/WladiD/AnyiQuack to work on FMX.

 

It offers some interesting animation and it relies on PPL.

 

[RonaldK 18]

On 10/2/2019 at 5:54 PM, Stefan Glienke said:

... At least the latter was solved by banishing those units from our code entirely and exclusively using spring4d collections.

What exactly is the problem here?
Do you have more info?

[Stefan Glienke 2002]

32 minutes ago, RonaldK said:

What exactly is the problem here?
Do you have more info?

I do and it will be subject of one of my talks I will be giving at some conferences in the coming months so I will not spoil that before.

[RonaldK 18]

5 minutes ago, Stefan Glienke said:

... I will be giving at some conferences in the coming months...

Do you have any links to the conferences?

 

Very nice to see that the Delphi users are still very active and very sad to see that Emba has almost completely dropped the rope.