The Daily WTF: Curious Perversions in Information Technology

Ford351-4V · 2006-08-10 Reply Admin

This is the best argument in favor of occupational licenses for coders that I have seen in a while. Letting an inexperienced Jerry spawn threads is like giving beer and car keys to teenagers.

2006-08-10 Reply Admin

You're right. Every good gangsta knows to use a (g)lock. Anything else might jam up on ya.

Grimoire · 2006-08-10 Reply Admin

drdamour:
Grimoire:

It is irrelevant whether or not the thread is correctly shutdown once the message was handled. The point is, a NEW thread was spawned every time a message was to be processed. How many messages per second is this service meant to handle? If you are spawning a new thread for every message, I can tell you it won't be many. This is what thread pools were invented for.

Imagine what happens when the system receives 100 messages in a second (the upper limit, based on the 10ms timer): the OS will practically thrash itself to death trying to build up and tear down threads that often. Nothing wrong with worker threads, but knowin' how to use 'em is kinda important yo.

Excuse my ignorance, but what would be the correct pattern for handling incoming (assuuming socket level) messages then?

I'd think you have a listener thread, that spans workers for every message it has. so is the WTF there that the worker thread was spawning a listner?

The correct pattern is for the listening thread to add the message to a message queue. There would then be a pool of threads whose job it is to grab messages out of the queue and process them. They would start at the beggining of the application, and run until the application was terminated. More threads could be added, or existing ones could be removed if you wanted to scale the application at runtime. This is known as a threadpool. There are a pool of threads that run, all of which have the same job. If the message queue is empty, the threads would simply wait (hopefully on a semaphore, rather than a while(queue.isEmpty()); // do nothing). This way, you have a nice multithreaded app that doesn't thrash threads.

And, it can be scaled. Have a machine with tons of RAM, 8 CPUs, and is expected to handle many messages per second? Fine, increase the threads in the thread pool. Running this on a 486 with 64MB of RAM? Knock it down to one thread.

Raider · 2006-08-10 Reply Admin

drdamour:
so why was it processing messages wrong?

Because he used *no* form of data synchronization ... Pure and utter race conditions ... In running benchmarks and data transmission tests, I had results number in the hundreds of thousands of messages lost, and dozens of crashes because of simple things like trying to access the .front() on an std::queue, while another thread just did a final .pop(), causing access violations, etc.

2006-08-10 Reply Admin

drdamour:
Grimoire:
drdamour:
Raider:

Anonymous:
I realy dont see a WTF here. And the snippet seams just fine (other than what it does ofc)...

Captcha: knowhutimean

You don't see a WTF in spawning hundreds of threads ?? Or using code found on places like codeproject.com in production applications ... Code that is most likely untested, or barely test, more often than not, not made by reputable developers/development groups/etc ?? .... Wow ...

so you're saying that when a message was received, that thread didn't die once the message was routed appropriately? I think the snipet could have been better, especially since the post implied that the snipet was responsible for incorrect message routing.

It is irrelevant whether or not the thread is correctly shutdown once the message was handled. The point is, a NEW thread was spawned every time a message was to be processed. How many messages per second is this service meant to handle? If you are spawning a new thread for every message, I can tell you it won't be many. This is what thread pools were invented for.

Imagine what happens when the system receives 100 messages in a second (the upper limit, based on the 10ms timer): the OS will practically thrash itself to death trying to build up and tear down threads that often. Nothing wrong with worker threads, but knowin' how to use 'em is kinda important yo.

Excuse my ignorance, but what would be the correct pattern for handling incoming (assuuming socket level) messages then?

I'd think you have a listener thread, that spans workers for every message it has. so is the WTF there that the worker thread was spawning a listner?

And how much of that snipet is of Alex's design vs what really was happening.

The correct pattern is for a listener thread to spawn workers. That way you can track and properly shutdown worker threads. Another good pattern for this is for the listener to utilze a thread-pool to do the work, that way you aren't creating and destroying threads which is an expensive operation.

The wtf is that the implemented solution is backwards from the normal way people spawn workers, and that there is no easy way to track or throttle the threads that could be created. Additionally there is no protection of data from access by multiple threads, as was stated in other comments, that the guy was really clueless in general, and somehow got by cutting and pasting samples that he got from the huge system of tubes in the sky.

Raider · 2006-08-10 Reply Admin

Grimoire:
drdamour:
Grimoire:

It is irrelevant whether or not the thread is correctly shutdown once the message was handled. The point is, a NEW thread was spawned every time a message was to be processed. How many messages per second is this service meant to handle? If you are spawning a new thread for every message, I can tell you it won't be many. This is what thread pools were invented for.

Imagine what happens when the system receives 100 messages in a second (the upper limit, based on the 10ms timer): the OS will practically thrash itself to death trying to build up and tear down threads that often. Nothing wrong with worker threads, but knowin' how to use 'em is kinda important yo.

Excuse my ignorance, but what would be the correct pattern for handling incoming (assuuming socket level) messages then?

I'd think you have a listener thread, that spans workers for every message it has. so is the WTF there that the worker thread was spawning a listner?

The correct pattern is for the listening thread to add the message to a message queue. There would then be a pool of threads whose job it is to grab messages out of the queue and process them. They would start at the beggining of the application, and run until the application was terminated. More threads could be added, or existing ones could be removed if you wanted to scale the application at runtime. This is known as a threadpool. There are a pool of threads that run, all of which have the same job. If the message queue is empty, the threads would simply wait (hopefully on a semaphore, rather than a while(queue.isEmpty()); // do nothing). This way, you have a nice multithreaded app that doesn't thrash threads.

And, it can be scaled. Have a machine with tons of RAM, 8 CPUs, and is expected to handle many messages per second? Fine, increase the threads in the thread pool. Running this on a 486 with 64MB of RAM? Knock it down to one thread.

Excellent explanation, and this is essentially what I made the replacement application do. It took 2 months and 150,000 lines of code to make the replacement and a company standard C++ library that takes full advantage of the C++ Standard Library and Boost, but our customers are a whole lot happier now that the program doesnt crash, and they actually get all the alarms coming in.

Grimoire · 2006-08-10 Reply Admin

Raider:
drdamour:
so why was it processing messages wrong?

Because he used *no* form of data synchronization ... Pure and utter race conditions ... In running benchmarks and data transmission tests, I had results number in the hundreds of thousands of messages lost, and dozens of crashes because of simple things like trying to access the .front() on an std::queue, while another thread just did a final .pop(), causing access violations, etc.

Well d'uh. It's obviously a crappy implementation of the std::queue. It should either work or not...

2006-08-10 Reply Admin

yay! threads... raider i feel your pain man

even for the most wizard programmer with the best programming and design practices threads are absolutely nightmares on single processors, not to even get into multi-processor beasts - debugging them is a downright pain in the ass.

CAPTCHA: perfection

2006-08-10 Reply Admin

oh.. and btw - this is the way i deal with multiple connection servers

I loop and check if data is ready on the listen connection, if so i accept the connection and add it to my connection list. I then loop through the connection list checking for data ready and processing any communication if data is ready.

pseudo-code

while (1)
{
     check-for-connections and accept them
   loop on connection list
     {
          check for communications and process
     }
    check for shutdown command - if bound break
}
disconnect all clients politely.

If i ever get into a large enough connection volume situation I would create a pool of threads where each thread is assigned a certain number of connections to handle.

2006-08-10 Reply Admin

Raider:
Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.

public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)
{
  //spawn a new listener so we can process this
  int h = CreateThread(
    NULL, 0, ListenForMessage,
    (void *)this, 0, NULL);

  //now process the message

How is this not spawning a new thread for every message?

I mean, the method name is "PrecessIncomingMessage" not "AcceptConnection" or something like that. There's a comment there that says "now process the message" after the new listener is spawned.

What if messages arrive over a UDP socket? That would be fun.

Captcha = clueless.

drdamour · 2006-08-10 Reply Admin

Anonymous:
drdamour:
Grimoire:
drdamour:
Raider:

Anonymous:
I realy dont see a WTF here. And the snippet seams just fine (other than what it does ofc)...

Captcha: knowhutimean

You don't see a WTF in spawning hundreds of threads ?? Or using code found on places like codeproject.com in production applications ... Code that is most likely untested, or barely test, more often than not, not made by reputable developers/development groups/etc ?? .... Wow ...

so you're saying that when a message was received, that thread didn't die once the message was routed appropriately? I think the snipet could have been better, especially since the post implied that the snipet was responsible for incorrect message routing.

It is irrelevant whether or not the thread is correctly shutdown once the message was handled. The point is, a NEW thread was spawned every time a message was to be processed. How many messages per second is this service meant to handle? If you are spawning a new thread for every message, I can tell you it won't be many. This is what thread pools were invented for.

Imagine what happens when the system receives 100 messages in a second (the upper limit, based on the 10ms timer): the OS will practically thrash itself to death trying to build up and tear down threads that often. Nothing wrong with worker threads, but knowin' how to use 'em is kinda important yo.

Excuse my ignorance, but what would be the correct pattern for handling incoming (assuuming socket level) messages then?

I'd think you have a listener thread, that spans workers for every message it has. so is the WTF there that the worker thread was spawning a listner?

And how much of that snipet is of Alex's design vs what really was happening.

The correct pattern is for a listener thread to spawn workers. That way you can track and properly shutdown worker threads. Another good pattern for this is for the listener to utilze a thread-pool to do the work, that way you aren't creating and destroying threads which is an expensive operation.

The wtf is that the implemented solution is backwards from the normal way people spawn workers, and that there is no easy way to track or throttle the threads that could be created. Additionally there is no protection of data from access by multiple threads, as was stated in other comments, that the guy was really clueless in general, and somehow got by cutting and pasting samples that he got from the huge system of tubes in the sky.

Ha, that explination totally reminded me of school and the whole producer/consumers thread model. Now i totally remember how to do it.

2006-08-10 Reply Admin

I meant "ProcessIncomingMessage".

Raider · 2006-08-10 Reply Admin

Anonymous:
Raider:

Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.
public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)
{
  //spawn a new listener so we can process this
  int h = CreateThread(
    NULL, 0, ListenForMessage,
    (void *)this, 0, NULL);

  //now process the message
How is this not spawning a new thread for every message?

I mean, the method name is "PrecessIncomingMessage" not "AcceptConnection" or something like that. There's a comment there that says "now process the message" after the new listener is spawned.

What if messages arrive over a UDP socket? That would be fun.

Captcha = clueless.

You must have overlooked the reply I put in that stated the code example Alex used, is just an example to illustrate the scenario, it is not an actual code snippet from the program.

2006-08-10 Reply Admin

Anonymous:
Raider:
Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.
public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)
{
  //spawn a new listener so we can process this
  int h = CreateThread(
    NULL, 0, ListenForMessage,
    (void *)this, 0, NULL);

  //now process the message
How is this not spawning a new thread for every message?

I mean, the method name is "PrecessIncomingMessage" not "AcceptConnection" or something like that. There's a comment there that says "now process the message" after the new listener is spawned.

What if messages arrive over a UDP socket? That would be fun.

Captcha = clueless.

because as he already said the code in the article is anonymized and isn't the real code - he's the submitter of the non-anonymized version

CAPTCHA: craptastic like your understanding of this thread

2006-08-10 Reply Admin

Anonymous:
MY GOD!!!!!! How do such STUPID people find work!

Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself.

That is a common piece of garbage! I was once asked if I had 5 years or more of experience with VB5, and I told them what I had(LESS THAN 5 years), and said that if ***ANYONE*** said they had more, they were LYING! Even the developer couldn't claim more, as the beta had changed a bit, etc... Still, they seem to ALWAYS want 5 years +, even if the product came out yesterday!

, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Actually, windows is a stupid imitation of X windows(which ran over UNIX) which came out a year BEFORE M/S Windows! M/S Windows ran over M/S dos(which came out about 4 years BEFORE M/S Windows) which was an imitation of CP/M (which came out over 5 years BEFORE M/S DOS and about 1 year BEFORE MICROSOFT!!!!!!). CP/M is obviously loosly based to some degree on UNIX which came out about 5 years before THAT!

MY GOD! The I.E.E.E. standard predates microsoft by about 4 years!!!!! NOT, WINDOWS, NOT DOS, but the ****ENTIRE COMPANY****

Eternal Father, Eternal One! Exceptions eternally? Absolute none! Doctor Bronner's 18-in-1 Pure Castile Soap to clean mind-body-spirit instantly uniting one! CAPTCHA "pacman"! ALL-ONE! ALL-ONE! ALL-ONE!

thatsteveguy · 2006-08-10 Reply Admin

Anonymous:
MY GOD!!!!!! How do such STUPID people find work!

Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself.

That is a common piece of garbage! I was once asked if I had 5 years or more of experience with VB5, and I told them what I had(LESS THAN 5 years), and said that if ***ANYONE*** said they had more, they were LYING! Even the developer couldn't claim more, as the beta had changed a bit, etc... Still, they seem to ALWAYS want 5 years +, even if the product came out yesterday!

, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Actually, windows is a stupid imitation of X windows(which ran over UNIX) which came out a year BEFORE M/S Windows! M/S Windows ran over M/S dos(which came out about 4 years BEFORE M/S Windows) which was an imitation of CP/M (which came out over 5 years BEFORE M/S DOS and about 1 year BEFORE MICROSOFT!!!!!!). CP/M is obviously loosly based to some degree on UNIX which came out about 5 years before THAT!

MY GOD! The I.E.E.E. standard predates microsoft by about 4 years!!!!! NOT, WINDOWS, NOT DOS, but the ****ENTIRE COMPANY****

<offtopic>
I didn't even think anyone else even REMEMBERED CP/M. It was on the first computer I ever used- as a child. It was on what was considered the first 'portable' computer, only it weighed in at over 50 pounds. It was called an Osbourne. </offtopic>

Heh. Nothing like the smell of burning server as it tries to maintain thousands of threads over YEARS, (I did read that was a possiblity above right?) It could be a mecca where thousands of programmers come every day to actually watch the poor unix box weep tears of blood.

Raider · 2006-08-10 Reply Admin

thatsteveguy:

<offtopic>
I didn't even think anyone else even REMEMBERED CP/M. It was on the first computer I ever used- as a child. It was on what was considered the first 'portable' computer, only it weighed in at over 50 pounds. It was called an Osbourne. </offtopic>

Heh. Nothing like the smell of burning server as it tries to maintain thousands of threads over YEARS, (I did read that was a possiblity above right?) It could be a mecca where thousands of programmers come every day to actually watch the poor unix box weep tears of blood.

Yes, you read that right .. There was a potential for thousands of threads to be running, for potentially years.

bholman · 2006-08-10 Reply Admin

The first problem Jerry was having was that the SME wasn't working on their target UNIX platform. Brian thought it was a bit odd and asked Jerry how he had developed it. Jerry responded, "using VC++6 and the MFC libraries."

This is a "for sure" wtf! Even without the multi-threading. I cannot imagine any MFC coder that wouldn't know VC code is windows platform specific. It is unfathomable to me.

Good one Brian!

2006-08-10 Reply Admin

Anonymous:

MY GOD!!!!!! How do such STUPID people find work!

Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself.

That is a common piece of garbage! I was once asked if I had 5 years or more of experience with VB5, and I told them what I had(LESS THAN 5 years), and said that if ***ANYONE*** said they had more, they were LYING! Even the developer couldn't claim more, as the beta had changed a bit, etc... Still, they seem to ALWAYS want 5 years +, even if the product came out yesterday!

, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Actually, windows is a stupid imitation of X windows(which ran over UNIX) which came out a year BEFORE M/S Windows! M/S Windows ran over M/S dos(which came out about 4 years BEFORE M/S Windows) which was an imitation of CP/M (which came out over 5 years BEFORE M/S DOS and about 1 year BEFORE MICROSOFT!!!!!!). CP/M is obviously loosly based to some degree on UNIX which came out about 5 years before THAT!

MY GOD! The I.E.E.E. standard predates microsoft by about 4 years!!!!! NOT, WINDOWS, NOT DOS, but the ****ENTIRE COMPANY****

Well I see that you enjoy the rich text editor...

YEP!

While MS-DOS was influenced by CP/M and CP/M was influcenced by UNIX, they are seperate systems with seperate aims.
MS Windows has absolutely no relation to the X Windowing System in any way.

They DO share the same basic concept. I was just showing how dumb the often accepted claim IS!

(And it's not called "X Windows" dammmit!).

OK, Sorry!

And WTF does the IEEE have to do with anything?

One "word".... P.O.S.I.X.!

PLUS, it is based on UNIX/C, and M/S HAS claimed to aspire to it.

Raider · 2006-08-10 Reply Admin

bholman:

The first problem Jerry was having was that the SME wasn't working on their target UNIX platform. Brian thought it was a bit odd and asked Jerry how he had developed it. Jerry responded, "using VC++6 and the MFC libraries."

This is a "for sure" wtf! Even without the multi-threading. I cannot imagine any MFC coder that wouldn't know VC code is windows platform specific. It is unfathomable to me.

Good one Brian!

Ever heard the expression "Ain't the sharpest tool in the shed" ? Hehe ... Honestly I'm really surprised the guy ever even got hired here ... I think he only squeaked by because the boss here is a VB developer, not C++, so he couldn't read "Jerry's" code and make any sense of it ... Once he saw the list of everything I found wrong with it "Jerry" immediately went on the "chopping" block .. It took him just over a year to make the app, and it sucked. I guess I put my own foot in my mouth when I made the replacement in just 2 months though, cause now that type of production is expected of me all the time :P

mallard · 2006-08-10 Reply Admin

Anonymous:
Anonymous:

MY GOD!!!!!! How do such STUPID people find work!

Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself.

That is a common piece of garbage! I was once asked if I had 5 years or more of experience with VB5, and I told them what I had(LESS THAN 5 years), and said that if ***ANYONE*** said they had more, they were LYING! Even the developer couldn't claim more, as the beta had changed a bit, etc... Still, they seem to ALWAYS want 5 years +, even if the product came out yesterday!

, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Actually, windows is a stupid imitation of X windows(which ran over UNIX) which came out a year BEFORE M/S Windows! M/S Windows ran over M/S dos(which came out about 4 years BEFORE M/S Windows) which was an imitation of CP/M (which came out over 5 years BEFORE M/S DOS and about 1 year BEFORE MICROSOFT!!!!!!). CP/M is obviously loosly based to some degree on UNIX which came out about 5 years before THAT!

MY GOD! The I.E.E.E. standard predates microsoft by about 4 years!!!!! NOT, WINDOWS, NOT DOS, but the ****ENTIRE COMPANY****

Well I see that you enjoy the rich text editor...

YEP!

While MS-DOS was influenced by CP/M and CP/M was influcenced by UNIX, they are seperate systems with seperate aims.
MS Windows has absolutely no relation to the X Windowing System in any way.

They DO share the same basic concept. I was just showing how dumb the often accepted claim IS!

(And it's not called "X Windows" dammmit!).

OK, Sorry!

And WTF does the IEEE have to do with anything?

One "word".... P.O.S.I.X.!

PLUS, it is based on UNIX/C, and M/S HAS claimed to aspire to it.

OK IEEE 1003 (aka POSIX) was ratified in the mid-80's. Microsoft was set up in the mid-70's. Microsoft predates POSIX by about 10 years.
http://en.wikipedia.org/wiki/IEEE_1003#History
http://en.wikipedia.org/wiki/Microsoft#1975.E2.80.931985:_The_founding_of_Microsoft

Not that it has any bearing. Yes UNIX was a very powerful server/workstation OS from the late 70's onwards. However, it is only comparatively recently that ordinary PC's have been capable of running UNIX well. In the past, less powerful, simpler OS's were needed. MS-DOS, MS Windows, CP/M, etc, were/are all OS's that were less powerful than UNIX purposely.

It has often been the case that an advanced technology is invented, but it is not practical for everyday purposes, and simpler, less powerful "copies" of the technology are invented and marketed.

Bus Raker · 2006-08-10 Reply Admin

Anonymous:
I'm guessing the low-quality code snippet site in question is expert-sexchange.com, what do I win?

I was thinking either that or tek-tips

Good places for syntax, bad for code.

Reminds me of an interviewee that brought in some code samples. He didn't even take the time to remove the credits from the comments (who were obviously not him)! Not to mention the samples were so old that they wouldn't even compile.

Bus Raker · 2006-08-10 Reply Admin

mallard:
Anonymous:

While MS-DOS was influenced by CP/M and CP/M was influcenced by UNIX, they are seperate systems with seperate aims.
MS Windows has absolutely no relation to the X Windowing System in any way.

They DO share the same basic concept. I was just showing how dumb the often accepted claim IS!

(And it's not called "X Windows" dammmit!).

OK, Sorry!

And WTF does the IEEE have to do with anything?

One "word".... P.O.S.I.X.!

PLUS, it is based on UNIX/C, and M/S HAS claimed to aspire to it.

OK IEEE 1003 (aka POSIX) was ratified in the mid-80's. Microsoft was set up in the mid-70's. Microsoft predates POSIX by about 10 years.
http://en.wikipedia.org/wiki/IEEE_1003#History
http://en.wikipedia.org/wiki/Microsoft#1975.E2.80.931985:_The_founding_of_Microsoft

Not that it has any bearing. Yes UNIX was a very powerful server/workstation OS from the late 70's onwards. However, it is only comparatively recently that ordinary PC's have been capable of running UNIX well. In the past, less powerful, simpler OS's were needed. MS-DOS, MS Windows, CP/M, etc, were/are all OS's that were less powerful than UNIX purposely.

It has often been the case that an advanced technology is invented, but it is not practical for everyday purposes, and simpler, less powerful "copies" of the technology are invented and marketed.

What would be the point of running UNIX on a workstation? Isn't the whole point to have a certailized mainfame and dummy terminals (TTYs).

That's just about as dumb as using Windows for a server! Ha ha ha

2006-08-10 Reply Admin

Anonymous:
"you can't use MFC if you ever want to compile something outside of Windows"

-- for what it's worth, you actually can buy a porting layer from mainsoft (www.mainsoft.com) that makes moving MFC projects to *nix pretty easy, or so they say.

I only know them because I still have a frisbee they gave me at a trade show a few years back...

I've heard of a similar porting layer from Oracle to SQLServer....

ParkinT · 2006-08-10 Reply Admin

Raider:

GoatCheez:
Alex Papadimoulis:
"Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Yup, just like how apples are based on frogs.... WTF lol...
That line literally made my job drop.

Yeah, I got a HUGE laugh when he said that to me ... I really thought he was kidding at first, but he wasn't, at all ... He was absolutely serious ... He had never heard of the C++ Standard Library, he had never heard of anything that wasn't MFC/VC++ related.

That brought to mind a little story I was told during a job interview (I was the applicant):

A previous applicant had a very impressive resume but the interviewer (a fellow developer) wanted to validate it. He asked this question: "Describe the Internet".

After a pause and what appeared to be serious thought the response was, "Object Oriented"

It is obvious he was not considered for the job!

ParkinT · 2006-08-10 Reply Admin

This story reminds me of a "real life" incident my son experienced during a C++ class in college recently.

Another student was accused, by most of the rest of the class, of stealing code from the Internet. It seemed obvious; he did not change any variable names, function names or even the comments.

Ultimately, the instructor reprimanded him for "COPYING COMMENTS". (not code)

Huh?

Zygo · 2006-08-10 Reply Admin

Anonymous:
"you can't use MFC if you ever want to compile something outside of Windows"

-- for what it's worth, you actually can buy a porting layer from mainsoft (www.mainsoft.com) that makes moving MFC projects to *nix pretty easy, or so they say.

I only know them because I still have a frisbee they gave me at a trade show a few years back...

I've used a number of applications built with that product. It really works, too--it reproduces all the bugs, hangs, crashes, and crappy performance of early versions of Windows perfectly...

Jeremy Morton · 2006-08-10 Reply Admin

ParkinT:

That brought to mind a little story I was told during a job interview (I was the applicant):

A previous applicant had a very impressive resume but the interviewer (a fellow developer) wanted to validate it. He asked this question: "Describe the Internet".

After a pause and what appeared to be serious thought the response was, "Object Oriented"

It is obvious he was not considered for the job!

Tubes are objects...

2006-08-10 Reply Admin

An ancillary wtf is the disdain against people who see portions of a wtf above, but likely don't have a good grasp on threads and so are trying to understand the problems involved in the sample above.

Assuming people are stupid because they don't know what you know or what you expect "everybody who knows anything" to know is presumptuous at best. Why not take the opportunity to point out flaws in the code, not the observers, and give the world one less opportunity for another wtf.

Zygo · 2006-08-10 Reply Admin

Anonymous:
I call shenanigans here. Half way through the method, the variable name changes from messageId to messateId. As far as I can tell (although it's been a while since I worked in C++), the only way this would compile is if there was a global variable called messateId, which is, well, unlikely.

[Note from Alex: this was a typo on my part]

The other month I reviewed some code from an inveterate Windows developer who is so reliant on VisualDevThingy that he is single-handedly porting our flagship Linux application suite to Windows just so he can use VDT to edit code. He uses cut+paste and automatic member/method name completion so heavily that even though he generates a huge number of typos, the code still compiles because the misspellings get copied to all the different places they need to be copied to for C++ to be satisfied. So far he hasn't gotten a virtual method name in a derived class wrong, but at this rate it's only a matter of time before one of these typos silently and subtly changes code behavior...

So I'd say that having a global variable (or an instance variable, or a base class instance variable, or a macro, or ...) named "messateid" is very likely indeed, even if Alex hadn't typo'd it. ;-)

2006-08-10 Reply Admin

I have a co-worker who is similarly in love with multi-threading. I was maintaining one of his apps that pretty much did everything by creating new threads. I got kind of fed up with the difficulties involved in stepping through the buggy code, and I asked him why he did this with a different thread. His response was "why not?"

I think people do this because they want to be able to say that their application is "multi-threaded", as if that makes it intrinsically a better application.

2006-08-10 Reply Admin

Alex Papadimoulis:
Raider:

Anonymous:
Just so I know to avoid it, which site is "known best for its presentation of astonishingly low-quality, unedited articles and code samples"?

I don't think I'm allowed to post on here what sites he found the code snippets on without getting Alex in trouble, but feel free to email the address attached to my profile here :)

I don't like to pick on specific companies or sites. But I figure that this reply will be burried far enough in the comments that a clue should be ok. The website in question (and I should note that I get a LOT of submissions directly linking to this site) starts with the the letter "c" and ends with "odeproject.com"

ARRRRRRRRRGGGGGGGGGGGGHHHHHHHHHHHHHHHHARRRGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHARRRRGGGGGGGGGHHHHHHHHHHHHHH!

CodeProject is one of my favourite sites for getting advice!!!!!!!!! ARRRRRRRGGGGGGGGGHHHHHHHHHHHHH!!!!!!!!!!!!!!

MANNNNNNNNNNNNNN!

What chance does a young man, having no formal training, being self taught in all aspects have when his favourite coding site is rubbished by his favourite "how not to do things" site!

ARRRRRRRRRGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHH!!!!!!!

GoatCheez · 2006-08-10 Reply Admin

Anonymous:
Alex Papadimoulis:
Raider:

Anonymous:
Just so I know to avoid it, which site is "known best for its presentation of astonishingly low-quality, unedited articles and code samples"?

I don't think I'm allowed to post on here what sites he found the code snippets on without getting Alex in trouble, but feel free to email the address attached to my profile here :)

I don't like to pick on specific companies or sites. But I figure that this reply will be burried far enough in the comments that a clue should be ok. The website in question (and I should note that I get a LOT of submissions directly linking to this site) starts with the the letter "c" and ends with "odeproject.com"

ARRRRRRRRRGGGGGGGGGGGGHHHHHHHHHHHHHHHHARRRGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHARRRRGGGGGGGGGHHHHHHHHHHHHHH!

CodeProject is one of my favourite sites for getting advice!!!!!!!!! ARRRRRRRGGGGGGGGGHHHHHHHHHHHHH!!!!!!!!!!!!!!

MANNNNNNNNNNNNNN!

What chance does a young man, having no formal training, being self taught in all aspects have when his favourite coding site is rubbished by his favourite "how not to do things" site!

ARRRRRRRRRGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHH!!!!!!!

I find that the site in question is not that bad if you just look at what they are basically doing, then close the page. It can give you a start in the right (although sometimes wrong) direction. If I'm using a feature I've never used before then codeproject does help, but I also use it along side other code examples doing the same thing.... After that it's pretty obvious what's kosher and what's not.

Zygo · 2006-08-10 Reply Admin

HeroreV:
The real WTF is that there is so little support for threads today. Try using a popular library in a thread and you'll probably get errors. You either have to reimplement things yourself or use special thread-safe libraries. Even the modern super-cool Boost library contains lots of stuff that isn't thread-safe.

Threads are slow. Any OS that actually has a decent thread implementation dies horribly in the marketplace because no software can be ported to or from that OS because the prevailing assumptions are so different. Even if you have a decent thread implementation, the overhead of constantly grabbing and releasing locks that you may or may not need to protect critical sections eats away at your performance. Sure, if you have a decent thread implementation, you might rearchitect your software to take advantage of it and replace the performance drain with performance gain--but who these days redesigns their software just to change platforms? It's about as hard as trying to get people to rewrite their software for BeOS.

Threads are decades old, but decent, commercially practical implementations of threads (outside of the embedded market) have been available for only a few dozen months.

The Boost library in particular, like many C++ libraries, aims to have zero overhead (i.e. the CPU spends zero clock cycles doing anything that isn't absolutely necessary for performing the documented tasks in the spec). Not "low" or "minimal" overhead--zero. Of course they'll never actually achieve that goal, but adding thread support is a giant step away from it.

Qt, on the other hand, is a popular C++ library full of wonderful thread-safe code. It also allocates multiple objects on the heap when you construct a simple list iterator--so expensive this is, that Qt itself avoids using list iterators in special cases like lists of one element. It has a very different notion of "high performance" than I do...

JustThat · 2006-08-10 Reply Admin

Can I get a WTF for how a large percentage of the recent posts have all been about new employees who have been on the job for 3 days?

Is 3 days some magical number for a coder? Or is it that it takes 3 days to get a computer and cubicle set up and get all the right passwords and the WTFs just jump out at good coders like they have on WTF-magnetic undershorts?

Raider · 2006-08-10 Reply Admin

Anonymous:
An ancillary wtf is the disdain against people who see portions of a wtf above, but likely don't have a good grasp on threads and so are trying to understand the problems involved in the sample above.

Assuming people are stupid because they don't know what you know or what you expect "everybody who knows anything" to know is presumptuous at best. Why not take the opportunity to point out flaws in the code, not the observers, and give the world one less opportunity for another wtf.

Some people just can't be taught ... I explained all the problems I found with his code, to him first ... Made recommendations, gave him links to standard specifications ... Even offered to let him borrow some of my library of C++ books, he was one of those "My code is the best, I don't care what you think" people ...

Raider · 2006-08-10 Reply Admin

JustThat:
Can I get a WTF for how a large percentage of the recent posts have all been about new employees who have been on the job for 3 days?

Is 3 days some magical number for a coder? Or is it that it takes 3 days to get a computer and cubicle set up and get all the right passwords and the WTFs just jump out at good coders like they have on WTF-magnetic undershorts?

Actually it took a day and a half for my desk and development machines to get set up ... But atleast I got the laptop the first day, loaded with the guys source code that I took home to review to learn since I figured we've both be working on the same code.

savar · 2006-08-10 Reply Admin

Alex Papadimoulis:
After only a few minutes of searching, Brian found code from nine different articles, all posted on a certain website known best for its presentation of astonishingly low-quality, unedited articles and code samples.

Was it this website?

Raider · 2006-08-10 Reply Admin

I think the overall worst thing about it was he was using seemingly random code snippets and just slapping them in a production application that is a major part of a Security System used in galleries, museums, banks, etc ... He knew almost nothing about the code he used other than that the website said it worked ... About the only thing I can really give him credit for is being good at taking random code, hacking it together and getting it to work just good enough that the boss didn't fire him for over a year ...

Zygo · 2006-08-10 Reply Admin

Raider:
Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.

IIRC, in Java up to version 1.3, one-thread-per-connection (actually, two threads if you want bidirectional communication) was the only way you could code such applications. No non-blocking system calls, no select or poll...but the runtime and JIT mechanisms were supposed to make threads really cheap and fast.

Zygo · 2006-08-10 Reply Admin

Anonymous:
A threadpool should be used and obviously the thread has to be cleaned up, however delegating the next listen to another thread (sometimes referred to as "Leader / Followers") is not unreasonable to use as it avoids a context switch.

What OS are you using where creating a thread doesn't cause a context switch...?

Raider · 2006-08-10 Reply Admin

Zygo:
Raider:

Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.

IIRC, in Java up to version 1.3, one-thread-per-connection (actually, *two* threads if you want bidirectional communication) was the *only* way you could code such applications. No non-blocking system calls, no select or poll...but the runtime and JIT mechanisms were supposed to make threads really cheap and fast.

And people wonder why daemons written in older Java were so slow and such resource hogs :) ... The only way I'd ever do one thread per connection is if there would be less than 10 connections on a single or dual core/cpu system and the connections have to be synchronous (Including ethernet, RS232, USB, etc, connections), otherwise I use a connection pool and if I feel it necessary, a thread pool to manage the connections.

2006-08-10 Reply Admin

Anonymous:
"you can't use MFC if you ever want to compile something outside of Windows"

-- for what it's worth, you actually can buy a porting layer from mainsoft (www.mainsoft.com) that makes moving MFC projects to *nix pretty easy, or so they say.

I only know them because I still have a frisbee they gave me at a trade show a few years back...

I dunno about mainsoft, but I myself did port big portions of MFC to run under unix, and everything went well. So you can use MFC if you really like and want. I certainly wouldn't do it with a greenfield project or one that is known to be ported right at the start, as there are better options today.

For this whole WTF, I can't make much sense of it. Well, the guy was not really u to the task; is that rare, fun or news-worthy? And yet another management took someone at face value without doing the most basic evaluation. Guess they deserve it then.

Raider · 2006-08-10 Reply Admin

Anonymous:

Anonymous:
"you can't use MFC if you ever want to compile something outside of Windows"

-- for what it's worth, you actually can buy a porting layer from mainsoft (www.mainsoft.com) that makes moving MFC projects to *nix pretty easy, or so they say.

I only know them because I still have a frisbee they gave me at a trade show a few years back...

I dunno about mainsoft, but I myself did port big portions of MFC to run under unix, and everything went well. So you can use MFC if you really like and want. I certainly wouldn't do it with a greenfield project or one that is known to be ported right at the start, as there are better options today.

For this whole WTF, I can't make much sense of it. Well, the guy was not really u to the task; is that rare, fun or news-worthy? And yet another management took someone at face value without doing the most basic evaluation. Guess they deserve it then.

The WTF isn't who HE was, it was what he was DOING :)

2006-08-10 Reply Admin

Ah, CodeProject.

I once got into an argument with an author there. He was convinced that the only time that the stack existed was when an exception was thrown.

Also, almost every article on there for .NET is lifted from MSDN or from another site, without any any credit given.

2006-08-10 Reply Admin

2 months and 150 lines of code... I hope that includes what was in the third party stuff, otherwise with no days off and working 10 hours a day you'd be writing a little over 4 lines of code a minute. That's not only fast typing but fast thinking. And I call it suspect.

2006-08-10 Reply Admin

Raider:

The WTF isn't who HE was, it was what he was DOING :)

Sure. You pick up a chop who ever in his life worked on VC++/Win, single threaded. And put him on a task writing multithreaded unix code. Without mentoring and supervision too.

Having done that I would NOT expect anything but code like presented here. And would have to blame myself. Like the king explained to the Little prince about issuing only *reasonable* orders...

2006-08-10 Reply Admin

Zygo:
Threads are *slow*. Any OS that actually has a decent thread implementation dies horribly in the marketplace because no software can be ported to or from that OS because the prevailing assumptions are so different.

You mean, like Linux?

Raider · 2006-08-10 Reply Admin

Anonymous:
2 months and 150 lines of code... I hope that includes what was in the third party stuff, otherwise with no days off and working 10 hours a day you'd be writing a little over 4 lines of code a minute. That's not only fast typing but fast thinking. And I call it suspect.

Erm ... I don't what what kind of code you write or have seen, but I'd hardly call that a lot ... It included the application itself, and the library I wrote for the company ... Generally I worked a minimum of 10 hours a day during the weekdays, and quite often more than that on the weekends ... Thats what happens when it becomes crunch time. Its was more or less a situation where I brought up all the faults in the previous app, and decided I could get it done faster and make it far more efficient if I rewrote it from scratch than to try and repair everything wrong with the original. Ever had one of those moments where you sat down, got an idea, and started writing code, and before you knew it the entire work day had gone by and you had generated 10000+ LOC ?? ... Happens quite often, especially on new projects where the entire design and purpose of the app is already laid out and it boils down to just writing the code.

Raider · 2006-08-10 Reply Admin

Anonymous:
Raider:

The WTF isn't who HE was, it was what he was DOING :)

Sure. You pick up a chop who ever in his life worked on VC++/Win, single threaded. And put him on a task writing multithreaded unix code. Without mentoring and supervision too.

Having done that I would NOT expect anything but code like presented here. And would have to blame myself. Like the king explained to the Little prince about issuing only *reasonable* orders...

Thats not exactly the case ... He said he could do it, he said he could make it work, etc, etc ... Its not like the boss said "Here, do this, and do it right, I don't want to hear anything more about it until its done" ... As close to everything as possible gets worked out in whiteboard sessions .. The problem isnt so much that he lacked the experience in developing for *nix as he lacked the knowledge of even the slightest differences between Win32 and *nix.

Flossin' My Threads

Leave a comment on “Flossin' My Threads”