Leaderboard

The only self explanatory code is the trivial one. In other situations there is no such thing as self explanatory code, especially if it also needs to be performant and thread-safe. I have written tons of self explanatory code, for which now I don't know what was I smoking at the time. Sometimes, after a lot of digging I can remember why it was written like that and why it should stay that way, but mostly no. So I am not sure if it was just crappy code from the times I didn't know better, or there are valid reasons behind the awkward design choices.

Considering the 1337 attitude of some developers ("well written code is self explanatory") they might just have the best Delphi coders in the world... however, seeing as the RTL and VCL are very often a source of inspiration and for learning, I would also appreciate more well written comments. Perhaps not line for line, but at least stating the intent of the following code block or the reasoning why this way was chosen over another.

Note that the person replying there Dmitry Arefiev is the same person that mentioned the solution here.

The performance issue may be resolved by replacing: // around line # 4383 CurMonitorStatus := FThreadPool.FMonitorThreadStatus; if Signaled then Continue; with: CurMonitorStatus := FThreadPool.FMonitorThreadStatus; if Signaled then begin FThreadPool.FMonitorThreadWakeEvent.ResetEvent; Continue; end;

Alright, I tested it in a console app it has a failure rate of about 1 / 35000 with 20 cores, that's too much. I wrapped adding new ThreadID's / ThreadObjects with a TCriticalSection. Thank you for making me reconsider my stubbornness.

No questions. Just a comment. This is not thread safe code. No amount of testing can prove that code is thread safe, you can only be lucky enough to catch the issue and prove it is not safe. But, just because it seems fine in your testing, does not mean it would never blow up.

FYI there is a reported issue on QP regarding the mentioned bug. It's a shame it isn't mentioned anywhere, I accidentally came across it by scrolling through the issues.

If so then it would probably be better if they implemented a proper rate-limiting mechanism. Looking at the Threading unit, it's rare to see professional code with this few comments. Is there some sort of rule within Embarcadero against commenting the code?

A good architecture, scalable architecture, is to have ONE thread for the server component for a given protocol. That thread will handle all client communications (that's OK for up to one thousand clients) and unload any processing to worker threads. You can also consider splitting the application between different processes which will handle a single protocol and possibly use IPC to make those processes talk to each other if required. Having a single process doing everything is the best way to have an unstable system almost impossible to debug.

Indy allows that just fine - provided you adequately serialize access to the socket to avoid multiple threads overlapping their outgoing packets. Although multiple threads CAN send to the same socket provided they don't overlap, it is generally a better idea to handle all of the sends in a single thread instead.

IMHO, just because the constant was DWord doesn't mean the variables should have been DWord.

Delphi: Only the subscription expires. The license remains valid.

This was changed in D12, in Delphi 11 it was declared as: const {$EXTERNALSYM CW_USEDEFAULT} CW_USEDEFAULT = DWORD($80000000); now it's: const {$EXTERNALSYM CW_USEDEFAULT} CW_USEDEFAULT = Integer($80000000);

A TListview is not designed to host other controls. Take a look at TControllist, it may be more suited to your requirements. Another option would be a TScrollbox with a number of instances of a custom frame (which are created in code as needed, each representing the data of a suitable object or record).

They are retooling the C++ compiler chain. I get the impression that C++ is becoming more important - not less - even if it might seem like a 2 steps forward, one step back (for the moment). My gut feeling is the future has never been brighter for C++Builder.

Perhaps on Tuesday during the 29th birthday webinar.

As mentioned in the blog: People just have different interpretations of shortly.