Leaderboard

Just a reminder for the next time anyone installs a Delphi update: TAKE A SNAPSHOT OF THE VM. And if you don't use a VM...reconsider and then just use one from now on. The hassle is reduced to a minimum.

I've managed to come up with something without having to patch FMX.WebBrowser.Android, but it still required Java code. I've put a demo here: https://github.com/DelphiWorlds/KastriFree/tree/master/Demos/WebBrowserFileChooser Note that it relies on other units in the Kastri Free project: https://github.com/DelphiWorlds/KastriFree ..including the compiled .jar, so you might want to just clone the repo and load the demo from it.

I know 🙂 But the number of threads doesn't matter to the correctness or falsehood of the assumption that strings are thread safe 😉 The high number of threads just helps to increase the probability of bad things to happen 🙂 And we want bad things to happen while we write and test the code, and not after we ship the software. When working with threads, one of the many problems is... it can work just fine... even, if there are problems in the code. At least for a while, on the development machine. The problems start rolling in, when you ship the software to some hundred customers. Then you will start to get strange bug reports from them. That is a very unlucky position to be in.

@Clément Sometimes simply moving problematic code to the end of the unit helped. Debugging in Rio is much worse than in Tokyo.

I have the impression that you can get the tokens from paylane. Other APIs have an endpoint. Maybe you can ask them

The devil is indeed in the details.

VirtualBox is really nice for making test VMs for Windows and Linux. Install your favorite Windows version in a clean VM. Hotfix it and adapt it to your liking. Clone it. Install 10.3.2. Snapshot it. Clone the original again. Install 10.3.3. Snapshot it. Voila! Side by side comparison is now possible.

Oh, it's really an old system... CPU: AMD Athlon II X2 RAM: 8 GB Video: Nvidia 9500 GT Screen Resolution: 1680 x 1050 Storage: 320 GB WD Blue OS: Windows 7 SP1 As I say, really ancient, but has worked just fine for anything I've wanted to do up to this point.

Added mine to the report (OnePlus7/Android10 if anyone wondering).

You can give Lazarus and FreePascal a try, at least that's what I do these days.

My CE licence ran out on Sunday, so this morning the licence wizard appears, I tried to download the new version but I received an email saying: 'Our records show that you have previously obtained a trial license for this product and version. A trial license can be issued only once. If you would like to extend the product evaluation, please contact Embarcadero Support' I have never downloaded a trial, only the CE version, so I have asked support for a new CE licence, if nothing comes then I guess it will be time to move to Visual Studio, I only use Delphi for personal and hobby applications so I can't afford the price of a commercial licence.

@Pawel Piotrowski Yes, but you launch 20 threads. My point was about a single write single read thread. But regardless my test also fails when increased to 10 million with single steps..

Lot of times in XE7, never in 10.3

Delphi Rio introduced new IDE styling (themes) that are not exactly super performant. If you have older computer, you might have some issues. I don't think you should have as much problem as you describe, but anything is possible. You can try disabling new IDE theming and use default Windows theme. You can find how to do that at https://dalijap.blogspot.com/2019/05/disable-delphi-rio-ide-theme.html I have to mention that using Windows theme is no longer officially supported and you can run into some issues because of that. I have been using Rio with default Windows theme since it was released and I didn't have any major issues (ones I did have - crashes in GetIt package manager and Find in files) have been resolved in the meantime.

For a Delphi string, it's never threadsafe if you have one thread writing and one thread reading. What is safe is the reference counting of strings. Copy-On-Write of Delphi strings is not a threadsafe operation. if you need a multithreaded read/write access to the same string you generally should use some synchronization, otherwise you are potentially in trouble. Example of what could happen without any lock. String is being written: it should become bigger than it was, so new memory is allocated. But pointer is not yet modified, it points to old string. At the same time reading thread got a pointer and began to read old string. Context switched again to writing thread. It changed pointer, so now it is valid. Old string got refcount 0 and was immediately freed. Context switch again: reading thread continues to process old string, but now it is access to deallocated memory which may easily result in access violation. dummzeuch is correct. Usually, you do not need to worry, Delphi plays nice and takes care for you. But if you want to know why non aligned memory access is not atomic, here is why: The problem is not limited to CPU instructions. In fact it has more to do with the data bus. When you have a 32 bit wide data bus, a read from memory is aligned on that boundary. So if you were to perform a 32 bit read from address 0x02, then two memory cycles are required, a read from address 0x00 to get two of the bytes and a read from 0x04 to get the other two bytes. You see, the first read fetches all 4 bytes from the address 0x00, discards the first 2 bytes. The second read fetches all 4 bytes from 0x04, and similar discards the second two bytes. After that the remaining bytes are combined to give you your 32bit data that you requested. This is not guaranteed to be atomic. A different CPU core could get its chance in between the above two reads to change the memory at address at 0x04, just before you read it. This is why you can not assume atomicity with non aligned variables. You might get lucky, because the CPU has multiple caches, and it might happen to be safe. But it is not guaranteed to be atomic. On a similar note, aligned memory is twice as fast to read/write, and this is why Delphi (and other compilers) align instructions and data in memory. I've build a small test, to see, how the following record will be aligned: Just for fun. TmyNiceRecord = Record i1: Integer; i64: int64; b1, b2, b3: byte; w1, w2: word; b4: byte; i2: Integer; b5: byte; b6: byte; b7: byte; End; who can guess which fields are aligned properly? Which are guaranteed to be atomic? Here are the results: for win32 build, with delphi 10.3.2 Address*| Aligned | VarName | VarSize 0 | Yes | i1 | 4 8 | Yes | i64 | 8 16 | Yes | b1 | 1 17 | No | b2 | 1 18 | No | b3 | 1 20 | Yes | w1 | 2 22 | No | w2 | 2 24 | Yes | b4 | 1 28 | Yes | i2 | 4 32 | Yes | b5 | 1 33 | No | b6 | 1 34 | No | b7 | 1 (* as an offset to the record itself) For win64 Address | Aligned | VarName | VarSize 0 | Yes | i1 | 4 8 | Yes | i64 | 8 16 | Yes | b1 | 1 17 | No | b2 | 1 18 | No | b3 | 1 20 | Yes | w1 | 2 22 | No | w2 | 2 24 | Yes | b4 | 1 28 | Yes | i2 | 4 32 | Yes | b5 | 1 33 | No | b6 | 1 34 | No | b7 | 1 interesting, isn't it? So, is delphi playing nice? Which fields can be assumed to be atomic? The answer is: All of them. Even b2 and b3. Yes, they do not start with a aligned address, but they do not cross the boundary either. This means, the read/write is still atomic. I hope that helps to better understand the topic. MemoryAlignedOrNot.zip

That's one reason why I don't work with packages installed by GetIt. Despite some efforts since the first appearance, it is still a half baked solution and not suitable for my environment and the way I work.

Thanks.. I've added my devices to the list.

Android 64bit debugging has issues on some devices. Debugging 64 bit Android application hangs the IDE https://quality.embarcadero.com/browse/RSP-26704 Can you please add information about your device - model and Android version to the above bug report.

Yes, I can compile our COM DLLs without UWP. I really don't have to use UWP. The reason I was exploring other options is that sometimes our components, when installed in COM+ servers, fail to perform well.. sometimes, admin has to kill dllhost on server. So I was wondering if UWP APIs can help me converting those COM components so that I don't have to rely on installing them in COM+ servers.