Anders Melander

And he even double posted his "response". I wonder if it's a bot

WTH? And it was closed before he reposted it verbatim here. I hate that. @turkverisoft If you're just going to ignore the advice you get you will not only be wasting your own time but more importantly the time of the people trying to help you. Now go stand in the corner. I'm out.

Unless you're running on a Commodore 64 you shouldn't be seeing such delays due to Sleep or WaitForSingleObject. There must be something else affecting the result but it's hard to tell without seeing your source. How many threads do you have running concurrently? Anyway, IO Completion Ports are generally considered the best way to get optimal performance in the scenario you describe. It should be fairly easy to find some examples of how to utilize them with Delphi. ...and don't mess with the thread affinity. Leave the thread scheduling to the OS. It's better at it and it shouldn't really be needed for something like this. P.S. Don't use Sleep(0).

If you were in my employ I'd fire you for doing something like that. What happens when a bug in your code causes your license check to fail and you execute corrupted code that wipes the customers disk?

Well, I must admit it's been at least 3 years since I last used AQTime on a 64-bit project, and I no longer have a license for it, so my memories of the experience might have improved with age. I'll need a 64 bit profiler for my current project sooner or later so I guess I'll get a refresher.

I've used both VTune and AQTime with 64-bit projects and I can't recall that I had problems with it. What's your experience?

Isn't that just the old TurboPower profiler. The UI doesn't seem to have been updated since then. Ugh.

Yes. AFAIK VTune requires PDB-files. I've tried various tds to pdb converters but AFAIR they didn't work.

In my experience you get what you pay for. None of the free profilers has ever worked satisfactory for me. I would recommend AQTime or VTune but they are both a bit expensive. I prefer VTune but as it doesn't support Delphi debug info it's only suitable for asm level profiling. It's excellent for that though.

Yes it is. The code you have posted will leak the TFDQuery instance and not return anything.

TBH I'm sure that I have suffered from this back when I was a rookie, but fortunately I quickly learned that it's not my problem. IME one of the primary causes of stress is the inability to understand this. People take responsibility for things that are beyond their control. There is no spoon. The cake is a lie. Etc.

No it's not that I haven't encountered it. I just don't consider it a problem. If a PHB decides to ignore my estimate based on his own opinion then that's his problem. Sure it might be demotivating developing something that you know will be late or unfinished because of that, but again; It's not my problem. It only becomes my problem if I revise my estimate based on pressure or try to meet an unrealistic deadline.

Never had that problem. The customer/manager might have their own opinion about the size/cost of a task but that doesn't really matter. What matters is the time/cost estimate I give them. Their opinion will not affect the outcome.

Plenty. You are trying to solve a problem you've created yourself by insisting on doing the mockup in Delphi. The solution should be obvious...

No disrespect but the same is true of many of those that have below average expertise - The Dunning–Kruger effect. I disagree but it doesn't really matter; The principles are the same regardless of the platform. Under any circumstances, at this point, your (and our) time would be better spent if you tried to locate the source of the problem instead of having everybody guess. Don't blame Windows for that. If you don't understand it then maybe leave threading to those that do. As far as I can see the majority of this thread is people restarting discussion about issues that have already been covered, people suggestion things to try and you trying it with no idea if or why it might or might not work.

Please read the whole thread before commenting. I already answered that and posted the relevant section from the SendMessage documentation. How would that help when: The cause of the problem isn't known. The original author of the code doesn't have good understanding of threading issues. The current maintainer doesn't either.

You are using static strings so there's no string allocation involved thus no corruption. The PChar will point to a constant string that never changes. Create the string with Format or IntToStr, as in my example, and you will get corrupted strings immediately. Also; Why WM_USER+1? Is WM_USER cursed?

You are off course correct: You are correct if the string resource is protected, but I'm not seeing any evidence of that. The string copy you're referring to happens in the message handler when the PChar is converted to a string, but before (or while) that happens the tread can have modified or free'd the source string. It's a race condition. Let's say the relevant code looks like this: // Thread procedure TMyThread.Execute; var Buffer: string; begin while (not Terminated) do begin Buffer := IntToStr(GetTickCount); PostMessage(MainWindowHandle, WM_STATUSOUT, WParam(PChar(Buffer)), 0); Buffer := 'Lorem Ipsum Dolor'; end; end; // Main thread procedure TMyForm.WmStatusOut(var Msg: TMessage); var Buffer: string; begin Buffer := PChar(Msg.wParam); OutputDebugString(PChar(Buffer)); // Or simply: // OutputDebugString(PChar(Msg.wParam)); end; I can guarantee you that you will see corrupted output.

Okay. I'll try again then. There are multiple problems in the original code. Like I said, Application.ProcessMessages in itself isn't a problem. The problem is that when you use SendMessage then the WMStatusOut method will run in the context of the thread which means that Application.ProcessMessage will also be executed in the context of the thread and that will definitely end badly at some point. Replacing SendMessage with PostMessage will take care of that (and get rid of ProcessMessages while you're at it. It's the mark of an amateur). Once the above is fixed, the more serious problem will surface: You're passing a pointer to a string owned by the thread to the main thread. You haven't posted the thread code, but I'm betting that there's nothing in your code to prevent the thread from modifying, or even freeing, this string once StatusOut has been called. I'm sure one of the usual suspects will be happy to provide you with an alternative solution.

While Application.ProcessMessages is evil it isn't the cause of the problem here. Use PostMessage instead of SendMessage. SendMessage calls the message handler directly and doesn't use the message queue at all. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendmessage

Whatever function you come up with it will be susceptible to race conditions; After you have determined that the file isn't in use, but before you can open and lock it, another process can come in and open it - or vice versa. Working from Remy's example you need to keep the file open after FileCreate. As soon as the file is closed the test result is stale.

It matches the indention style though

The threading library doesn't matter if you don't understand how to solve the problem and you won't learn by having other people solve it for you. It's a fairly simple problem and there's a gazzilion different ways to solve it. Why not give it a go on your own?

Imagine if your browser worked that way. Page slow to load? Sorry - You'll have to wait until it loads until you can try something else.

Okay, here's what I would do: First of all I would use TThread instead of tasks as that will give you better control of thread lifetime and resources (the bitmap). Let the thread own the bitmap. Remember to lock the thread canvas when you start and unlock it when you're finished. This prevents the VCL handle cache (controlled by the main thread) from messing with the bitmap while you're working on it. The thread also owns a windows event object. The thread signals this event when the render has completed. This allows the outside to wait or poll for for render completion. When the event has been signaled the render is complete and it's safe to access the bitmap. The tricky part is deciding when to destroy the thread. Since the thread owns the bitmap you can't have the thread destroy itself when it's done. On the other hand if you "forget" about any existing thread when a new thread is started then these old threads cannot be destroyed when they're done. If you have a good understanding of race conditions and synchronization objects then this can be solved fairly easy (but it's more complex than I have time to explain now). Otherwise I suggest you just keep a list of threads. Add new threads to the list and remove from the list and free when a thread has signaled completion. At some point you will have to go through the list and remove and free the old threads.