The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I read the report because I was expecting to see 2-3%, but it was 23% - so I looked at the methods and poll questions. It looks like the problem is you can't trust people to accurately judge and report on their own abilities.
For example, I've some 2600 threads on one machine and 1200 threads on another) according to Task Manager.
No, I don't want to look at them in proc explorer, and I tried googling that question, but what I'm looking for is just some high level (doesn't need to be technical) information of what the OS is doing. With nothing open except Task Manager, I have 1144 threads.
Any links, wisdom, or bad warp and woof weaving puns?
Look at how many services you have running. Each of those has two threads minimum, most will be in the range of 5 to 10 threads with some having more some having less. My virus scanning services have 300+ threads.
Its just easier to code tasks that need to wait on things single threaded, than it is to code some sort of async programming model. After all, a lot of that window code was written back in the late 90's.
Marc Clifton wrote:
bad warp and woof weaving puns
Just an amusing observation. Got discussing weaving the other day with a friend, only to to have my dog join in. His comments were surprisingly relevant.
The original Windows programming model didn't use threads. Everything was event driven: The entire application was waiting for something to happen, implemented as a new element in the message (/event) queue. The message was processed, conceptually by event concepts, that is: instantaneously.
Telecommunication people have programmed this way, using FSMs and state diagrams, since Day 1 of communication protocols. Other programmers never caught onto the way of thinking (although I have been using a disassembler written as a FSM: Recognizing an instruction prefix, an addressing mode or whatever were modelled as events).
Event/FSM modelling and programming is a completely different programming discipline. I haven't seen it taught in universities for at least twenty years. Nowadays, I don't think the lecturers are aware of it at all - not even in telecommunication courses. It really is a pity; event driven programming does have a lot of advantages.
Threads came in as an alternative, with all its problems. But people (especially those wiht *nix background) embraced it anyway. Every now and then I am itching to implement a complex protocol in a pure FSM manner, just to demonstrate how clean it could be. Even though other programmers might say: Yes, that looks great! I have no hope of making them do things that way themselves, though, so I never spent significant resources on it.
Last Visit: 31-Dec-99 19:00 Last Update: 2-Mar-21 13:27