[Estimated Reading Time: 6 minutes] Sometimes when you launch a thread you don’t know when it will complete whatever processing it is tasked with. Sometimes you do. Sometimes it may never complete and will require that you expressly terminate it. Usually any given thread will have a lifecycle that is at least consistently one or the other, but sometimes you will come across an awkward thread which is not so straightforward. Sometimes you will be creating a thread on behalf of somebody else who is making these decisions.
[Estimated Reading Time: 6 minutes] Although I am using Oxygene a lot these days, Delphi remains my tool of choice for Win32 (and x64) development, together with the VCL. Hence this post. A long time ago, in a galaxy far far away, Delphi was a Windows only development tool. 16 was the number of the bits with which it was concerned, and 1 was the number of threads in the process (though it was not called a thread). It was a simpler time. Then the bits were doubled and the number of threads did multiply, but it was important still that some things happened only on the original thread, though for a time a blinded eye could be turned since – no matter the plurality of threads – with only one piece of silicon to share, only one thread could be running at any one time. Yet lo, TThread.Synchronize() was conceived.
[Estimated Reading Time: 5 minutes] In the previous post in this series, we saw that the number of threads that a given process could support was determined by a number of factors, of which the stack size reserved for each thread was key. We also saw how we could change the stack size used by our application and how this could increase the number of threads that our process could support. But if you thought it seemed a bit crude to have to set a single stack size for all the threads in a process (including the main thread), then you would be right, and we can do something about this.
[Estimated Reading Time: 6 minutes] Roberto Schneiders recently drew my attention to the first post on his new blog (which I can recommend as a good read 🙂 ), presenting the results of some performance testing of DataSnap that he had been involved with which proved to be very interesting (if initially somewhat disappointing). But my post isn’t about that, at least not directly.