Originally Published: Tuesday, 2 October 2001 Author: Ian Beard
Published to: opinion_articles/opinion Page: 1/1 - [Printable]

Linux : Dead End?

The Linux.com Opinion section is great because so many of our written opinions and so many of the comments left by our readership are so intelligent and well reasoned. In this article Ian Beard has a point to make to fellow Linux programmers, and it seems like a darn good point to us and he says it well. You may or may not agree with him, but Beard's argument is at least a pragmatic one, and not just more FUD, and thus it has a place on Linux.com Opinion. Tell us your opinion today!

   Page 1 of 1  

Well, it had to happen. When a snowball starts rolling down a hill, picking up speed and more snow, it reaches a point where no one is interested in what lies at the heart of the snowball; except, that is, when it hits you.

And it hit me quite hard. Unless the Linux community provides a decent multi-threaded development environment any company that has a requirement to develop multi-threaded software on Linux will soon find out that they have an impossible task.

As a real-time developer of financial server software, developed mostly on Microsoft Intel platforms, developing multi-threaded applications is my bread and butter, it's what I do best. The operating system and development tools used should fully support the multi-threaded environment.

With Microsoft this certainly is not a problem. One can even say Microsoft is biased towards the multi-threaded approach. When it came time to take a serious look at Linux, naturally the development was going to involve multiple threads.

I realize you must try to understand Unix from its origins. In Unix of the past it was more important for the processes to be autonomous, communicating with each other through shared memory or ports. A parent process spawns a child or children and each process, be it parent or child it is simply a single threaded program. The problem with this approach is how do you debug a coherent system consisting of several hundred processes, acting as one system. There is the small matter of portability. POSIX was put on earth so solve portability issues and the POSIX thread library is a wonderful piece of commercially viable software. So when threads hit Unix, and became standardized, they actually became (in my opinion) a better solution than that provided by Microsoft. POSIX threads have a much better way of terminating, you can push termination routines onto the thread stack. When a thread dies suddenly and unexpectedly you have to opportunity to clean up, even call a c++ class destructor. With NT they are supposed to support this feature, but it has a bug - it does not work!

After porting the multi-threaded libraries and then successfully developing and running simple test applications, I was ready to throw a full-scale project at Linux. It's at the point where the project is 90% complete, after consuming a huge amount of time and resources, you hit a serious bug, which requires a multi-threaded debugging environment.

Currently GDB does not seem to support multi-threaded debugging environment. No GDB graphical user Interfaces seems to either. It can be done with SmartGDB - if you want to go back to an old kernel and seriously modify the system.

What is the point of developing server based software for a server based operating system if there is no supporting server development environment? Any operating system that ships without a reasonable development environment is doomed. It will never be used in anger or adopted by the professional business community. It will always be regarded as "Micky Mouse" and for enthusiasts and hackers use only.

So, what to do? Desperately you try to browse the Internet, looking for solutions. You try downloading various debuggers, only to find out that they are all front-ends to GDB. You look at something called SmartGDB, but realise that the individual who started the project got bored or fed up with putting years of time into the project and decided to move on, leaving the project frozen in time (a serious problem with Open Source). So your only solution is to create a special debugging kernel at an old version of the kernel (2.1) just to debug multiple-threads. Not a solution one wants to support in a commercial environment.

It looks like the only other approach open is to develop and debug the software on a different operating system, and then compile it on Linux and hope for the best. In my opinion this makes Linux not commercially feasible. Imagine putting these words into a contract "if the software fails to compile and run on Linux we cannot be held responsible".

The Linux community must make a decision, they must decide if they wish to attract the business community and come up with better development tools. If they fail to do this Linux will be a victim of Techno-Fashion.

Looks like its time to crack open Solaris for the Intel Platform.

About the author: I have been developing financial software for 15 years. First accounting systems, then joined Thomson Financial (5 yrs) and worked on debt instrument and equities data distribution systems (on VAX, PC and Wang). Moved on to Arcontech (5 Yrs+) where I developed real-time systems, worked on software for testing Satellite modem devices, operating system layers for iRMX, NT (new serial device driver, NT's was too slow) and now Unix. Currently porting Arcontechs City Vision real-time financial trading systems to Unix. Other than that I am currently taking my PPL (25 hours, 1 solo), and hope to own/fly my own plane by 2003.





   Page 1 of 1