This blog has moved. Please update your bookmarks.

Because of the way things are going, I've decided I might as well get a domain of my own.

So through foresight and fortitude, I have now registered the domain; and I am now moving my blog to this location. This means that anyone who reads this site, will have to move over to the new one.

Since it's ultra-brand-new, it may still take some 24 hours before the DNS servers throughout the world learn about the address, but it should work OK by now I think.

Thoughts About Threading

Threading, as I've mentioned before, is hard. Especially in non-managed languages, such as Delphi for Win32.

Various people, including Allen Bauer, is thinking about how languages can be adapted to support thread-based development easier:
"This increases the need for the average developer to be become more adept at writing multi-threaded applications. What if the compiler and the libraries made this easier and more accessible? It is these kinds of questions we ask ourselves everyday..."

One way of doing it, I'm thinking, is to have the compiler automatically generate warnings or errors in certain cases. We've patched the ZeosLib library so different threads cannot access ZConnection objects created in other threads; the ZConnection objects keep track of thread ownership and refuse to work for other threads (unless manually overriden). This behavior causes exceptions to be thrown in this case, which is far more desirable than having access violations deep inside one's code.

Just tossing ideas around, why not have certain attributes (I'm inspired by C#) that specify thread access? Like, for instance,
procedure TForm1.Log(const Text: string); mainthread;
... main-thread code here ...

Certain attributes might specify whether, like in this case, a method may only be accessed from a main thread; or with another attribute "threaded", special vigilance may be required and certain patterns may be enforced by the compiler. A function marked as "thread-unsafe" may not be called from a "threaded" method without certain encapsulation or something.

I think there are lots of things that can be done. Delphi/Win32 right now is at the same level that C++ were with strings (back when C++ was actually used by people). It can be done, but it's all manual, hard labor. Even few changes can yield significant returns.

Green Tea Sucks

Yep. Can't stand it.

Nightmares on Serialization Street

Serialization is the process of taking an object, and streaming the contents of that object into a file, or communications channel, or any other form of media; and then rebuilding that object on the other side, so that it takes up the exact same representation as it did on the sender side. Think of it as a Star Trek teleportation device, but for data objects - the data objects being represenations of invoices, computer commands, telephone extensions or more complex forms of data.

Delphi has this for TComponent objects, but not for anything else. So I've had to build a complete serialization layer, using such fancy classes and interfaces such as ISerializable, TSerializeBuffer, TSerializeObjectHelperRTTI, TSerializeObjectHelperNoElements, TXmlInterfaceSerializer (which isn't complete), all available through functions like SerializeObject, UnserializeObject and PeekSerializedClassName, through heavy use of variants and run-time type information.

To further agonize over this, this is but one part of the problem. We're building server flashes into our system, meaning that a specific information-gathering part of our programs can run in three different ways: 1) through normal execution, 2) threaded execution to provide application responsiveness even though a task is executing, and 3) a server-based remote object call, placing the heavy burden on the server instead of the client.

I don't know how this happened, but somehow, I find myself building a complete client/server-based remoting layer into a language that doesn't have it; and interfacing that remoting layer with dynamic fail-over to local methods in case the link goes down.

Isn't this what the wizards at Sun or Microsoft are supposed to be doing?


Blog contents copyright © 2005 Mats Gefvert. All rights reserved.