Leaderboard

@Darian Millerhas published a very nice article about the state of TThreadedQueue and TMonitor in Delphi. He has also published at Github a stress test that shows how TThreadQueue still fails under stress. I have played with his stress test and concluded that the problem is almost certainly in TMonitor. TMonitor implements a lock-free stack to recycle events created with the CreateEvent function. The relevant code in SysUtils is var EventCache: PEventItemHolder; EventItemHolders: PEventItemHolder; procedure Push(var Stack: PEventItemHolder; EventItem: PEventItemHolder); var LStack: PEventItemHolder; begin repeat LStack := Stack; EventItem.Next := LStack; until AtomicCmpExchange(Pointer(Stack), EventItem, LStack) = LStack; end; function Pop(var Stack: PEventItemHolder): PEventItemHolder; begin repeat Result := Stack; if Result = nil then Exit; until AtomicCmpExchange(Pointer(Stack), Result.Next, Result) = Result; end; This lock-free stack is used by NewWaitObj and FreeWaitObj which are part of the Monitor support protocol and used by TMonitor. This works reasonably well, but under stress it fails. The reason it fails is known as the ABA problem and is discussed in a similar context by a series of excellent blog posts by @Primož Gabrijelčič: blog post 1, blog post 2, blog post 3. His OmniThreadLibrary contains the following routine that he uses to deal with this problem. /either 8-byte or 16-byte CAS, depending on the platform; destination must be propely aligned (8- or 16-byte) function CAS(const oldData: pointer; oldReference: NativeInt; newData: pointer; newReference: NativeInt; var destination): boolean; asm {$IFNDEF CPUX64} push edi push ebx mov ebx, newData mov ecx, newReference mov edi, destination lock cmpxchg8b qword ptr [edi] pop ebx pop edi {$ELSE CPUX64} .noframe push rbx //rsp := rsp - 8 ! mov rax, oldData mov rbx, newData mov rcx, newReference mov r8, [destination + 8] //+8 with respect to .noframe lock cmpxchg16b [r8] pop rbx {$ENDIF CPUX64} setz al end; { CAS } I have tried to use this function to provide a solution for TMonitor similar to the one in OmniThreadLibrary. (see attached iaStressTest.TThreadedQueue.PopItem that can be used with the original stress test). Whilst still not perfect it helps a lot in 32 bits with say up to 100 threads. However it crashes in 64bits and I do not know why. I am posting this here in case anyone with better knowledge than mine of assembler and thread programming can help with the challenge of fixing TMonitor. It would be nice to try and get a fix included in 10.4. And even if it is not included, it can be easily used as a patch in the same way as in the attached code. iaStressTest.TThreadedQueue.PopItem.pas

Hi there, I have seen already a few blogs talking about the new feature internals of the coming Rx10.4 release: https://www.delphiworlds.com/2020/05/its-time-to-get-excited/ https://blog.marcocantu.com/blog/2020-may-per-control-styling.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+marcocantublog+(marcocantu.blog) https://www.uweraabe.de/Blog/2020/05/15/delphi-10-4-leverages-vcl-styles/ https://dalijap.blogspot.com/2020/05/delphi-nullable-with-custom-managed.html https://community.idera.com/developer-tools/b/blog/posts/new-vcl-tedgebrowser-component-coming-rad-studio-10-4 https://community.idera.com/developer-tools/b/blog/posts/adopting-the-openjdk-for-delphi-android-development I hope this is ending the long, long favorized age of "SORRY, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul". Hurray: That is a very good step in the right direction, open information instead of information hiding I'm with it, and this gives all customers an early insight in the new features they might have been waiting for, in a more technical perspective rather marketing. We trust our MVP's to give good advices, that also lead to make decisions about prolonging our subscriptions (so there is a little marketing inside anyway, thats fine).

The rest is a guess based on historic practice. Makes me just as right or wrong as any other speculator. 😉

@Dany Marmur Sorry, I was over overexcited now its getting better .... Pfffffffffffff

I also have a wiki page on 10.4 containing many of these links that I try to keep current: https://github.com/ideasawakened/DelphiKB/wiki/D27.SYDNEY.10.4.0.0

The data you are seeing is not *encrypted*, it is *compressed*. You are telling the server that you will accept responses in a compressed format (on top of encryption used by SSL/TLS), and the server is choosing to actually send a compressed response (you can verify that by looking at the TIdHTTP.Response.ContentEncoding property after the response arrives), however you have not setup TIdHTTP to actually decompress the compressed data for you, so you are seeing the compressed data as-is (well, after it has been String'ified, anyway). Get rid of that assignment to the TIdHTTP.Request.AcceptEncoding property (unless you really want to try your hand at decompressing the data manually). Instead, assign a TIdZLibCompressorBase-derived component, such as TIdCompressorZLib, to the TIdHTTP.Compressor property, and let TIdHTTP manage the AcceptEncoding property for you based on the compressor's capabilities. Don't call the TIdLogFile's Open() and Close() methods directly. Use its Active property instead, which will call Open()/Close() for you: IdLogFile1.Active := True; try LResp := IdHTTP1.Get('https://www.trivial.com.br/envia_arq3.php?senha=violeta&nome=tre'); finally IdLogFile1.Active := False; end; Calling Open() will open the log file you specify, but any sent/received data will not be logged to the file if Active is False.

It should be: function setCategoryWithOptionsError(category: NSString; withOptions: AVAudioSessionCategoryOptions; error: PPointer): Boolean; cdecl; But you don't show how you're calling it, either. A possible example: var LErrorPtr: Pointer; LError: NSError; ... setCategoryWithOptionsError(CocoaNSStringConst(libAVFoundation, 'AVAudioSessionCategoryPlayAndRecord'), 0, @LErrorPtr); if LErrorPtr <> nil then begin LError := TNSError.Wrap(LErrorPtr); // Deal with LError here end; You should. No. I suggest filing a QP report.

Yes, Sleep()/usleep() really does block the calling thread, stopping it at the OS level, yielding to other threads so they can run, for at least the specified time (may be more). TEvent.WaitFor() is waiting for its internal event/semaphore object to be signaled by TEvent.SetEvent(), up to the specified time. During that wait time, the calling thread is stopped in a blocking sleep, yes. It is just using a different API to accomplish that.

If that's aimed my way, I'll gladly take it. I had more days than I can count starting at 8am and leaving work the next afternoon without sleep due to some crisis. CTO for 22 years at a highly active software company where we were always under-staffed, over-promised, and working on a shoe string budget (privately held, one man owner for much of that time until I became a minority owner.) I don't miss it, much. (My wife certainly doesn't.) The cool thing - we had 11 Delphi developers at one point and I was trying to hire another when the VC people showed up and bought us out. But even with that many developers I left the place with 5,000 open tickets on the tech side of the house, after spending a solid year concentrating on getting it down from a much higher number. (My custom built trouble-ticket system had 500,000+ tickets in its mid-2004 to late 2018 history.) But my history suggests - take the walks. There's always a crisis. And if you want some useless code tested for fun, send it my way. I may just do it.