Dalija Prasnikar

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.

I cannot comment on deadlock trigger being too sensitive as I haven't explored that part of code and its behavior much and whether solution for the deadlock by expanding threads is the most appropriate one. However, you are using separate pool for your parallel for loop. So there is no danger of it deadlocking. You just need to set UnlimitedWrokerThreadsWhenBlocked to False and that pool will be restricted to the number of threads you have specified. function TThreadUtils.GetLoadflowThreadPool: TThreadPool; begin if not Assigned(LoadflowThreadPool) then begin aThreadLock.Enter; try if not Assigned(LoadflowThreadPool) then begin LoadflowThreadPool := TThreadPool.Create; LoadflowThreadPool.SetMinWorkerThreads(TThreadPool.Default.MaxWorkerThreads div 2); LoadflowThreadPool.SetMaxWorkerThreads(TThreadPool.Default.MaxWorkerThreads div 2); LoadflowThreadPool.UnlimitedWorkerThreadsWhenBlocked := False; end; finally aThreadLock.Leave; end; end; Result := LoadflowThreadPool; end; Of course, this might not be enough if you have other pools that run intensive tasks that can create excessive number of threads which can slow down everything.

The reason for expanding number of threads is to avoid deadlock with nested TParallel.For loops. If you want to use old behavior then you should set UnlimitedWorkerThreadsWhenBlocked to False on each ThreadPool you are using, including the default one. For any other issues you mention, there is nothing we can do if you don't provide details about your code and implementation of your parallel loop mechanisms. While it is always possible that there are other bugs in System.Threading, it is also quite possible that your code has bugs, too. Just because you get access violation in Delphi RTL code, that does not mean that the cause is not in your code. For debugging multithreaded applications, especially the ones that spawn many threads, it is more suitable to use logger and inspect code behavior through logs instead of using debugger. Debuggers are usually too intrusive for multithreaded debugging that involves more that few of background threads as it severely impacts timing.

This is for C++ Builder PRO TERM LICENSE https://www.embarcadero.com/products/cbuilder/product-editions Delphi doesn't even have such option.

Did the message came from the IDE or your application? Without having the message text and your code it is hard to diagnose what is wrong. Also, there are no critical sections in Vcl.Dialogs.

I somehow missed that one. Yes, this one looks serious. I don't know what is the status of this issue. I thought that my.embarcadero.com was also impacted by the outage. Anyway, I phrased my sentence a bit awkwardly, like the outage could be the only reason why fixes are not released yet as patch also needs to go through testing phase before it is finally released.

You mean the issue with division with $FFFFFFFF constant? That is nowhere near being a showstopper bug. As a workaround it is possible to use variable instead of constant. And this issue is fixed, but at the moment hotfix cannot be delivered due to outage.

Only you know that. But, if you are asking is Delphi dead, then the answer is No, it isn't. This was just a hiccup (even though, a huge one), and the resolution is just around the corner.

It is possible to have a dependency manager that does not have a single point of failure. There are probably others, and this is not exactly package manager as such, rather a build tool, but Gradle has a good dependency manager. https://docs.gradle.org/current/userguide/declaring_repositories.html Solution to a server being a point of failure is having multiple servers, and extension of that is that you allow user customizable list of servers (multiple ones) That way, if one server goes down other's would be available and it can be easy to extend the list with new servers if required. Once you have that, you can easily have even your own private server for distributing your own built packages within the company.

I wonder who has such landline these days. Our telecom switched to VoIP long ago. So I have a land network connection, but we no longer have classic telephone line.

https://docwiki.embarcadero.com/RADStudio/Athens/en/XML_Documentation_Comments There are also tools that can help in writing those, so you don't have to do that manually, like https://devjetsoftware.com/products/documentation-insight/

I don't think they or anyone needs advice from AI.

I meant that JIRA Server is no longer supported https://www.atlassian.com/migration/assess/journey-to-cloud and this was known for some time. Their internal JIRA will be migrated fully. So there will be no loss of issues in internal system. As far as the public one is concerned, I don't know whether it will be migrated or not and what are the possible issues. Evidently, it will not be migrated right away.

Moving QP is not about saving money, nor it is directly related to current outage. It was something that has been planed for quite some time (this has been disclosed to MVPs) because Atlassian no longer supports JIRA on premises which Embarcadero uses. https://blogs.embarcadero.com/embarcadero-quality-portal-migration/ So they are logically moving their internal system to Atlassian Cloud and the front for customers will use Jira Service Management. It would be rather ridiculous to use full fledged JIRA for customers and pay millions for features that we couldn't use anyway. JSM seems like a good option in this case. And issues will be visible to everyone.

Your assumption is correct. And like you said self hosted JIRA is no longer an option. AFAIK, there is an option to set visibility of all issues to be automatically visible to all customers, but that option is not a default one. So I don't think visibility should be a problem here.

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/ GetIt is still off line, but you can download RADStudio 12 ISO. There is a download link in that blog post.

I have multiple Delphi version installed and working on my machine, including Delphi 11 and 12. They all work fine. Installing new version didn't break my old versions. So the question is what you have done to have your Delphi 12 installation break Delphi 11 installation?

Only problem you can face is if you are using dynamically loaded packages as the RTTI for that package will point to invalid memory. But I am not sure how relevant is that to the macOS as I don't know if you can even use runtime packages there. Thanks! I added the test project.

AFAIK, Idera runs the whole IT infrastructure for multiple companies under their umbrella.

Yes, it will call EnsurePoolToken, but if the global token already exists it will not lock PoolLock while it tries to create one.

Yes, this looks like a classic deadlocking bug. One thread locks one lock, while another locks other and they are dead in the water. It should be reported. Possible workaround would be acquiring context at the application initialization (with KeepContext) and releasing it on shutdown. That way you would prevent EnsurePoolToken called from KeepContext to lock PoolLock.

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

This is why I said that this was not a software problem, but a hardware problem. Beyond that anything anyone says is pure speculation.

It is directly dispatched in TCustomForm through procedure CMRelease(var Message: TMessage); message CM_RELEASE;

CM_RELEASE is simple procedure TCustomForm.CMRelease; begin Free; end; Yes, you can intercept it in your form.