Leaderboard

We create all these in code. No visual components used. We have no sea of DB components floating in designers. It requires a bit more scaffolding code, but it can be generalized and made threadsafe.

It sounds like you already know the answer to that one.

This is not possible because constructing forms and controls also interacts with the OS in thread-unsafe way. For instance creating window has thread affinity and window belongs to a thread that creates it. You cannot construct window in one thread and pass it to another. If you remove initialization code that interacts with OS and other thread-unsafe parts, controls would need to have separate initialization that would need to be synchronized with the main thread. This would be rather messy as different controls have different requirements and construction of controls would get additional layer of complexity which would also only slow things down. Forms streaming also uses global lock mechanism to protect global namespace (data modules can be constructed and streamed in background depending on used components), so adding synchronization during loading forms would also open potential for deadlocking, and preventing the deadlocks would also require additional calls and checks which would again slow everything down. This never worked in VCL and it does not work in FMX. Threading issues can be hard to catch. Just because you can create some components in background thread without immediately bumping into issues does not mean such code is bug free.

In small demo applications, I use a TDataModule with component dropped on it. For real world large application, I use a simple unit have the code that encapsulate database access and database components are created at runtime. The unit offers classes that give access to the data stored in the database in an abstracted way. More code but much better program if correctly designed.

The challenge is that to do the drawing, you need a long series of calls to retrieve device info as well as setting up values and UI elements. When accessing the UI in it self is not threadsafe in the underlying OS - it becomes pretty much impossible. Windows UI APIs - not threadsafe Linux Gnome GDK/GTK+ - not threadsafe Android UI toolkit - not threadsafe Apple iOS UIKit - not threadsafe and creating the control structure is such a miniscule task in itself. Of course you can build data structures, models, etc in a thread, but the real work happens towards the UI - which cannot be made treadsafe.

Plenty. User interfaces in general (not just Delphi) are not thread-safe. Thread safety comes with hefty price. You would have to lock just about everything and it would significantly slow down the UI. Also, UI controls are complex and have plenty of interactions. Due to that complexity, making UI thread-safe would be complicated and error-prone. Not only that, but UI needs to interact with OS layer where UI controls are also not thread-safe as such where you cannot access the same control from different threads. That means if you would construct one control in background thread to be used in main thread afterward, not only you would have to make sure that interaction with Delphi UI side of controls have to be thread-safe, but control would have to avoid triggering any code that interacts with OS part which is almost impossible. UI is not thread-safe by design and that is something that will not change as it is not practical nor beneficial. There are some parts around handling images that could be fixed to fully support processing images in background threads and then passing them to the UI for presentation.

There's info about it here: https://firebase.google.com/docs/crashlytics/ndk-reports. There is also: https://firebase.google.com/docs/crashlytics/get-started?platform=android#java however since Delphi apps are native, I expect the former is more relevant, and it includes the SDK version as well anyway. A quick glance tells me that it should be able to be integrated into a Delphi app, however it appears it may need the same treatment as described in: https://quality.embarcadero.com/browse/RSP-20000 Next week I plan to release version 1.6 of Codex - the changes include functionality that is intended to help with this process.

Just an excerpt from the mormot2 tests (win32, win64 numbers look similar) running on an i7-12700 10.4.2 - Custom RTL: 297,648 assertions passed 285.77ms FillChar in 9.37ms, 41.4 GB/s Move in 22.25ms, 14 GB/s small Move in 25.05ms, 4.3 GB/s big Move in 25.06ms, 15.5 GB/s FillCharFast in 8.21ms, 47.3 GB/s MoveFast in 42.99ms, 7.2 GB/s small MoveFast in 17.15ms, 6.3 GB/s big MoveFast in 26.59ms, 14.6 GB/s 11.3 - Custom RTL: 297,648 assertions passed 247.86ms FillChar in 6.37ms, 60.9 GB/s Move in 10.10ms, 30.9 GB/s small Move in 17.98ms, 6 GB/s big Move in 14.77ms, 26.4 GB/s FillCharFast in 7.37ms, 52.6 GB/s MoveFast in 42.76ms, 7.3 GB/s small MoveFast in 16.83ms, 6.5 GB/s big MoveFast in 27.69ms, 14.1 GB/s The first 4 are RTL functions, last 4 are mormot implementations. Take this with a grain of salt though as these are just unit tests and not a performance benchmark but it gives a little idea. FillChar has already been improved by me for 11.1 and Move will be in 11.3 (along with other improvements in the core RTL) No, this is not suddenly making your applications twice as fast but solves the old complaints of FillChar and Move being sooo slow. 😉

In theory when writing and GUI framework from scratch, it could be possible to make that framework thread-safe. But drawing is not the only part that needs to run in the main thread. Any interaction with the OS - creating OS handles (like windows, graphic objects...), mouse interaction, keyboard interaction, OS notifications, needs to run in the main thread. too. Also access to all resources would have to be protected by locks. That means every single field and property inside control. So while background threads would be running doing some work on those controls, UI thread would not be able to use them. Now it may look that this would still be solution if you want to just create and destroy controls in background threads, but again to do that safely ALL access ALL the time have to run through locks, That means even if you never use background threads, accessing and working with UI controls would be much slower ALL the time. Multithreading is not cost free. I don't know what is your intent behind the question. Again, the fact that FMX is not thread-safe is not a flaw in its design, or anything similar. It is because thread-safe UI frameworks are basically non existent (I am saying basically, because like I said in theory they are possible, but I don't know about any). All major OS-es have thread-unsafe UI frameworks: Windows, Linux, Android, iOS, macOS - simply because making those thread-safe does not make sense. Thread safety is not just about throwing locks around some lists, but also defining what interactions need to logically happen without any interruptions from other threads. That would mean locking would have to extend to much broader code besides just accessing lists, and the more complex the scenarios (and UI are extremely complex frameworks with complex code paths) the more chances are that there will be bugs and concurrency issues that cannot be easily resolved. Patching FMX to add thread-safety is impossible as it is not just adding few locks here and there, it would have to be thorough rewrite. If you want to write your own framework, you are always free to do so, but I would have to ask "You and what army?"

Is there a reason why you don't use the original InterBase installer and select Client Only in the Choose Install Set dialog? Where did you get the information, that the steps you describe are sufficient?

Very astute observation. Do a little research on autism and Asperger's if you're interested in understanding it better. I was diagnosed two years ago and am still learning about it and how it affects how I interact with the world. Autism is a genetic condition that affects about 2.5% of the population, and about 20% of that is on the "Asperger's" end of the spectrum. So it's not exactly rare, but not easily recognized. More to your point, there's something in my mind that seems to make me feel that I'm constantly misunderstood, and I have lots of evidence of that, so I over-compensate. Psychologist said it's "normal" for how my brain works and is never go away, so I gave up trying to "fix" it. The easiest way to think of it is that people with Asperger's are relatives of Mr. Spock and have some Vulcan heritage. Observant Star Trek fans might recall that Kirk got along well with Spock, but McCoy had a really hard time dealing with him. I'm pretty sure his character was modeled a lot after someone with Asperger's. And there's no need to apologize. Just consider that there's a common believe most people have that says, "Everybody thinks the same way I do." Even a lot of certifiably crazy people think that. It's not true. In fact, most people do tend to think alike. That's called "neuro-typical". But a lot of people are what's called "neuro-divergent", including those with autism, and our brains just don't seem to be wired the same as most "neuro-typicals".

This

Mine takes the SQL table create statement and creates the wrapper class in Delphi, as well as the database stored procs.

Thank you Peter & Remy, I wasn't aware that TCanvas was sharing resources, the D7 documentation on lock/unlock refers to use lock to prevent other threads from writing to the canvas, but since my code wasn't accessing the canvas from outside the thread, I didn't think locking was mandatory. I have now changed the code to lock all 3 canvases outside the thread loop. Sherlock: It's funny how one person's confusing syntax is exactly the opposite for another person, I hate using "not" in any boolean check because for me it's confusing with logical (bitwise) operators. John Kouraklis I'm not sure what you mean. I use "csThumbRenderer" TCriticalSection in a try/finally block to copy over the contents of TBitmaps from the main thread. I use the same critical section in the main thread as well when accessing these bitmaps, so there should be no case where the bitmaps are used concurrently by more than one thread.