Just released eBook: Delphi Event-based and Asynchronous Programming

-

 Delphi Event-based and Asynchronous Programming 




I just had to do it... Go with the flow!

It's the Black Friday / Cyber Monday "season", so I had to rush the book offer :slight_smile:

The book was actually scheduled for release in early December, but then the Black Friday deals started popping up all over the place... pressure was building... and I finally caved in!

I cut the darn thing in two, and decided to offer Part I at a discount, and will give Part II for free to all Buyers. Not really a 97% BF discount but hey... Junior is still studying, and we still have to pay the bills (Corona doesn't help, either)!

So, here it is! :slight_smile:

I hope you'll like it like you did Delphi Memory Management!

https://dalija.prasnikar.info/delphiebap/index.html


Event-based programming is everywhere. Nowadays, you can hardly write any kind of application without leaning on events and messages.

This simple, yet extremely powerful mechanism is also the cornerstone of asynchronous and multithreaded programming. Without events, we would not know when some task was completed.

But, asynchronous and multithreaded programming consists of more than just handling multiple threads, protecting shared resources, and synchronization. It also includes designing and understanding program flow. That design aspect is often forgotten, taken for granted, and solving all the fine-grained nuances of multithreaded programming hogs the spotlight.

Without understanding asynchronous flow and the bigger picture it can be hard to properly solve all the other issues, including multithreading. What used to be plain spaghetti code, now becomes temporal spaghetti.

You can lose control over your objects, have bits of code creating and releasing them all over the place, even without adding multithreading into the mix. Memory leaks, crashes, and holding references to dead data long after its destruction are perfectly possible even in a single-threaded environment.

While the starting point of this book is giving a proper introduction to event-based and asynchronous programming flow and design, it also provides the necessary implementation details, explanations and code examples needed to put those designs into practice.


 

Table of Contents
Part I. - Sections 1-4

Introduction

1. The Loop

Hidden complexity
Peeking at the console
Main event loop
Event-based programming
Pushmi-pullyu
Game loop

2. Messaging Systems

Windows messaging system
Windows messaging system in VCL
Custom messaging systems and patterns
System.Messaging

3. Life, the Universe, and Everything

Life, the Universe, and Everything
Automatic memory management
Interfaces
Class helpers
Anonymous methods and lambdas

4. Asynchronous Programming and Multithreading

Asynchronous programming and multithreading
Making the first dive...
Application.ProcessMessages
Application.ProcessMessages reentrancy problem
Moving long operations to a background thread
Asynchronous message dialog
Tasks
Futures
Coming in Part II. on December (11) 28, 2020

*Due to a minor accident, the release date may slide for a few days!

Part II. - Sections 5 & 6

5. Thread Safety

What is thread safety anyway?
The importance of thread safety
Achieving thread safety
Avoiding shared data
Protecting shared data

6. GUI and Multithreading

Main (GUI) thread
Communicating with the main thread
Communication and GUI issues

Comments

  1. Bruce McGeeNovember 25, 2020 at 4:45 AM

    Any timeline on physical copies?

    ReplyDelete
    Replies
    1. Bruce McGeeNovember 25, 2020 at 4:46 AM

      Oh, and congratulations!

      Delete
    2. Dalija PrasnikarNovember 25, 2020 at 12:06 PM

      Thanks!

      Timeline, no. It's planned though.

      eBook version will be out for a while first. I'll wait for more feedback and eventually release an eBook update before the print is out.

      At the moment, we're adding finishing touches to Part II that will be out early December...

      Delete
    3. Dalija PrasnikarFebruary 10, 2021 at 3:47 AM

      Paperback edition has just been published. For all eBook purchases, there is 50% discount on paperback edition.

      Links and instructions for getting discount for already purchased eBooks are at: https://dalija.prasnikar.info/delphiebap

      Delete
  2. UnknownDecember 2, 2020 at 3:22 PM

    Hey Dalija,

    Anderson here. First, congratulations!!! You're a brave woman and I wish this would set an example for other women to engage in technology. Especially in Delphi, which is a male dominated field. We will all benefit from that.

    Second, where can I find your books to buy?

    Cheers,
    A

    ReplyDelete
    Replies
    1. Dalija PrasnikarDecember 7, 2020 at 2:45 AM

      Hi,

      for purchasing you can follow the links on the side (or in above article for Async Programming)

      You can also find direct purchase links for all books on https://dalija.prasnikar.info

      Delphi Memory Management is also available on Amazon.

      Delete

Post a Comment

Popular posts from this blog

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more

Beware of loops and tasks

-
Loops and anonymous methods don't go hand in hand. Any variable that changes for each iteration will cause problems if it is used within an anonymous method. I explained the mechanism behind variable capturing in the post Mysterious Case Of Wrong Value , along with the problem it causes with loops and its solution. Commonly, anonymous methods are used as callbacks or event handlers, where there are no loops in the context where variable capture happens. While there is a possibility to have an unexpected—wrong—value in such scenarios, it is rather easy to debug them and understand the order in which some code is called, and why the captured value is wrong in a given place. With the rise of multi-threading usage, and especially the Parallel Programming Library and tasks, writing anonymous methods inside a loop becomes more common, and it is much easier to write code where a captured variable will have the wrong value. The biggest problem with such code is that it will be harder to
Read more

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more