Primož Gabrijelčič

OmniThreadLibrary 3.07.8 has just been released. It contains few small fixes + support for Delphi 10.4 Sydney. Changelog: New features: Implemented IOmniTask.RegisterWaitObject with an anonymous method callback. [Jacek Laskowski] donated a new OTL icon (res\OTL.ico). Added Delphi 10.4 Syndey packages. Bug fixes: [sglienke] A reference to an anonymous method executor in IOmniTask is cleaned up as soon as possible. This allows OTL tasks to be executed from a package. [issue #132] TOmniMREW.TryEnterReadLock and .TryEnterWriteLock were returning True on timeout. SetOnMessage(nil) works correctly. Fixed invalid FreeAndNil of an interface in TOmniFuture<T>.Execute. Compiles with Delphi 10.4 Sydney. https://github.com/gabr42/OmniThreadLibrary/releases/tag/release-3.07.8

Thank you, @Dalija Prasnikar, I just wanted to post exactly that 🙂 New release should go out this weekend.

Indeed, OnTerminated is the correct approach.

Does this not already work out of the box? If a task is finished, WaitForAll should now that.

Call stack depth is configurable in FastMM4. {------------- FullDebugMode/LogLockContention constants---------------} const {The stack trace depth. (Must be an *uneven* number to ensure that the Align16Bytes option works in FullDebugMode.)} StackTraceDepth = 19;

Check the stack trace to see where this critical section is allocated from. If this is not possible with the FastMM that comes with Delphi (frankly, I don't use it and I have no idea), use FastMM from git and define FullDebugMode conditional.

This is not possible at the moment. You have to implement your own registration mechanism - register a task in some structure when you create it, deregister it when it is completed.

Oh, that was you! Big thanks! For the record - I'm trying to keep the book in sync with the OTL most of the time.

Without having a reproducible example, I have no idea. Yes, you need a new pipeline. After a pipeline goes into CompleteAdding state, it cannot be "revived".

Done. OmniThreadLibrary now uses only the DSiWin32 part and ignores DSiWin32.VCL.

Ah, I get it. I don't like to break compatibility but this is something that could be useful, indeed. Alternatively, I may move this functionality into DSiWin32.VCL (which may be altogether a better idea).

Defining NoVCL where? I don't understand.

I have fixed that (just now). DSiWin32 no longer uses Vcl.Graphics if symbol NoVCL is defined.

Oh, a classic mistake 🙂 Been there, done that.

Sure, TOmniBlockingCollection is fine.

I don't know. Show us the code. You are probably doing something after that "WaitFor" and I don't know what. What is confusing here? You don't have to wait for pipeline to terminate (WaitFor) to start processing its output.

I would love that too!

You can probably use PostThreadMessage Windows API to post a message directly to the main thread. Then you process this message in your process loop.

Of course you can run a pipeline without a WaitFor. You have different options to detect when a pipeline has finished its work. a) The main program can count the number of items sent to the pipeline and number of items returned from. (If there is a simple correspondence between two - for example if each input produces exactly one output.) b) The pipeline itself can detect that it has no more work and then it can signal this to the main program. When you detect a terminating condition, you can shut down the pipeline (with WaitFor) and you'll done. See the "folder scanner" in OTL examples folder for an example of the b) technique or read this chapter of the book: http://www.omnithreadlibrary.com/book/chap10.html#howto-webDownload

There is none. Only the main thread should update the UI in a VCL application so if it is blocked, you're out of options. In theory, you could create a window purely by the Windows API and use it to show the progress, but that is probably much to much work. Better solution would be to not block the VCL application at all.

Presentations and code are available here. I'll send you a link to the video recording as a private message.

When the WorkItem is freed. Usually that happens after it is dispatched to your notification handler (OnRequestDone, OnRequestDone_Asy).

Delphi 10.3.2, IDE Fix Pack 6.4.4 When I close a project with File, Close All, I get this error: This happens with all projects. Startup Layout.dst attached. @jbg Startup Layout.dst

That helps, thanks!

You are missing a reproducible test case 😉 Sincerely, I have no idea. If the example works for you (you tested it, probably?) and the application doesn't, you'll have to find what that difference is.