Opinioned, incomplete comparison of OmniThreadLibrary and darkThreading (http://chapmanworld.com/2018/05/24/a-new-mutlti-threading-library-for-delphi-darkthreading/)
Opinioned, incomplete comparison of OmniThreadLibrary and darkThreading (http://chapmanworld.com/2018/05/24/a-new-mutlti-threading-library-for-delphi-darkthreading/)
I spent half of my time today to dig into darkThreading.
Why?
===
I'm refactoring the multi-thread part of a program, decided to make it as much *FPC-ready* as possible.
Note, OTL is a very good and versatile threading library for Delphi, if the mentioned program would always stick with Windows I won't consider switch ATM.
Observations
===
- like OTL, darkThreading has an *lockless* *inter-thread communication* module that supports multi-sender-one-receiver mode which is just what I need. Actually an
inter-thread communication channel is my main (of not only) reason to use a 3rd party threading library.
- As opposed to OTL's inter-thread communication module's implemented using Windows messaging, the one in darkThreading's implemented using array thus is more *crossplatform-friendly*
- By browsing the source code, one can find that darkThreading is designed with cross-platform in mind.
- darkThreading's source code is much small in size and much easy to read and easy to understand.
- darkThreading's very very well and *completely commented* in the source code thus it's very easy to consult the docs while coding, whereas with OTL I need to read the PDF book by pj (don't get me wrong, I was very willing to pay for the book).
- darkThreading's recent github commits shows that it's progress for FPC support. Even if the developer doesn't do that, its 'interface for everything' design makes it very easy for one to add FPC support IMHO.
PS
1 - I don't mean to start a war at all but just to share the result of hours of researching.
2 - I guess Craig Chapman the author of darkThreading is not in the group? I realized he's an EMBT employee, I guess the info about FPC exposed in this post wouldn't induce any pressure from his upper management? I wish it won't, hehe.
That's all for now and I'll experiment the code later on.
http://chapmanworld.com/2018/05/24/a-new-mutlti-threading-library-for-delphi-darkthreading/
I spent half of my time today to dig into darkThreading.
Why?
===
I'm refactoring the multi-thread part of a program, decided to make it as much *FPC-ready* as possible.
Note, OTL is a very good and versatile threading library for Delphi, if the mentioned program would always stick with Windows I won't consider switch ATM.
Observations
===
- like OTL, darkThreading has an *lockless* *inter-thread communication* module that supports multi-sender-one-receiver mode which is just what I need. Actually an
inter-thread communication channel is my main (of not only) reason to use a 3rd party threading library.
- As opposed to OTL's inter-thread communication module's implemented using Windows messaging, the one in darkThreading's implemented using array thus is more *crossplatform-friendly*
- By browsing the source code, one can find that darkThreading is designed with cross-platform in mind.
- darkThreading's source code is much small in size and much easy to read and easy to understand.
- darkThreading's very very well and *completely commented* in the source code thus it's very easy to consult the docs while coding, whereas with OTL I need to read the PDF book by pj (don't get me wrong, I was very willing to pay for the book).
- darkThreading's recent github commits shows that it's progress for FPC support. Even if the developer doesn't do that, its 'interface for everything' design makes it very easy for one to add FPC support IMHO.
PS
1 - I don't mean to start a war at all but just to share the result of hours of researching.
2 - I guess Craig Chapman the author of darkThreading is not in the group? I realized he's an EMBT employee, I guess the info about FPC exposed in this post wouldn't induce any pressure from his upper management? I wish it won't, hehe.
That's all for now and I'll experiment the code later on.
http://chapmanworld.com/2018/05/24/a-new-mutlti-threading-library-for-delphi-darkthreading/
How about Tests available for both? A suite a tests goes a long way to help understand and validate usage.
ReplyDelete/sub
ReplyDeleteThanks. Much appreciated.
ReplyDeleteI have not heard about this library before. Interesting...
ReplyDeleteDarian Miller Sorry but I don't have such a plan unforunately, browsing the source, browsing and running the examples is enough for me to evaluate it.
ReplyDeleteNo offense but you can hardly compare that with OTL. darkThreading is just a few basic building blocks for threading nothing more.
ReplyDeleteStefan Glienke Actually it's not a complete comparision, In terms of functionality I agree that OTL is more feature rich and powerful. But in my specific case, all I need is an inter-thread communication module, and I want my program to be more FPC-compatible, OTL's communication channel is Windows message based, and you'll won't be able to migrate it to FPC for Linux. So darkThreading is a good fit.
ReplyDeleteI agree, I wouldn't personally compare it to OTL. OTL originally started the same way, intended for building some kind of Game engine but it grew into a feature rich threading library. darkThreading on the other hand, remains for the purpose of building a game engine, and so it's features are driven only by what that project needs.
ReplyDeleteThat said, the author has tried to keep the code compatible with fpc/lazarus, even going to the trouble of rewriting portions of the code to allow for broken generics support (for record types) in freepascal.
I'm not overly concerned with the 'higher ups' at EMBT learning that my code supports Lazarus. While there are those that see Lazarus as a competing product (which from a business perspective, makes sense), I see it as a complimentary product. I've always loved fpc, and have been using Lazarus for various personal projects since the project first re-emerged.
For various reasons however, I would never select Lazarus to build a commercial product, and since the launch of Delphi's community edition, would no longer use it for most personal projects either.
The main use I have for fpc, and therefore the reason for maintaining source code to support it, is for reaching those targets which Delphi does not support. This is why darkGlass and it's support libraries attempt to remain compatible (and .lpk's are being added).
My primary focus will always be Delphi.
Thanks for the positive review Edwin.
Craig Chapman Hey Craig, thanks for your reply and for the great contribution on darkThreading, I especially appreciate the FPC compatibility!
ReplyDeleteI'm not using it for games, but I've been using the inter-thread communication classes for building a mechanism that allows raw TThread instances to communicate with each and the UI, it's been a great success!
Great to hear it!
ReplyDeleteCraig Chapman A dream of mine would be the Linux compiler to be included in Delphi CE or at least the Professional Edition, and mORMot supports, haha!
ReplyDeleteRE: "OTL originally started the same way, intended for building some kind of Game engine but it grew into a feature rich threading library. "
ReplyDeleteNope. OTL started as a threading library for building multithreaded server applications.
Primož Gabrijelčič My mistake :-D Perhaps I confused it's history with another library.
ReplyDeletePrimož Gabrijelčič I'm not sure how I came under that wrong impression, but I remember what I was reading at the time. I take it you were not responsible for the game engine architecture posts at otapi.com?
ReplyDeleteCraig Chapman No problem at all :) And no, I have nothing to do with these posts.
ReplyDeleteUpdate: Though I know it will disappoint some I removed the dedicated GitHub project for darkThreading, and rolled it into darkGlass which is updated far less frequently.
ReplyDeletedarkThreading has a new home however, at digitalenvysoftware.com - darkThreading – >IGITAL ∑NVY which has had some minor updates to make integration with the main loop easier and to improve lazarus support.
Very soon, I'll be adding a (minimal-feature) task pool, and resolving the missing unit tests.