|
Didn't know you were American.
|
|
|
|
|
Why would any sane person want to speak French??? 
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
Le singe est dans les arbres avec la plume de ma tante etc.
Easy peasy, n'est-ce pas?
That said, it doesn't tend to take people overly long to get bored of conversations about monkeys, trees, aunts and pens, so I naturally revert to the old Anglais.
And, yes, 23%!? Whoever wrote that report clearly hasn't met many English folk.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
How many can actually carry on a conversation in English?
|
|
|
|
|
By the way - my remark was not a comment on emigrants or immigration. It was a comment on the inability of some native speakers of a given to carry on a conversation.
|
|
|
|
|
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.
|
|
|
|
|
Something is out of whack, thats for sure. 23% Ha!
|
|
|
|
|
|
European Commission only reports about EU citizens... 
|
|
|
|
|
Britain is in the EU dufus.
|
|
|
|
|
What is the 'EU dufus'?
|
|
|
|
|
The political area you live and yourself.
|
|
|
|
|
|
We dont need luck, we are British, the masters of the earth.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
How many of them are active, and how many are blocked and simply waiting for something?
I tend to spawn a lot of threads; anything the user does, anything that needs loading, anything that does not need to be done in the mainthread.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Marc Clifton wrote: Any links, wisdom
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.
|
|
|
|
|
In the original windows programming model, everything had to be event driven because there were no threads. It was also all based off the windows messaging model, which was closely linked to having a window.
When threads were added, they were predominantly for background tasks, and as such it was a major pain to give them a windows message pump so you could write them event driven (you had to give them a hidden window). So, for that kind of background processing, there was a shift toward just writing the code single-threaded and using multiple threads.. unless you needed gobs of threads, in which case you used some sort of thread pooling (which, IIRC, there was no library support for at first).
I seem to recall this being the recommended practice from the teacher back when I took my Win32 programming class at MS.. but this is a lot of years ago, so maybe I misremember it all... 
My point was, that was the prevailing best-practice when a lot of that system code was written, and I doubt it's been rewritten since.
|
|
|
|
|
The classic Mac OS was the same way - purely event driven. (I learned the philosophy of event driven programming by reading about Mac OS several years before I encountered Windows in pratice!)
In the classic Win32 model, events were routed to an entity called a 'Window', because it almost always had one. But it didn't have to! Today, a 'process' serves the same role: Like a window entity handled a number of events, and the processing of them, the 'process' handles a number of threads. The main difference is that while processing an event (i.e. a message) always completed within a short time, a thread may stop midway, waiting for 'something' - the 'something' is not modeled as an event/message, but as something else.
Note that in *nix (as well as many other OSes), the 'process' is an actively executing entity. Threads are just subdivisions of the activity within a process. A Windows process is not by itself executing; it is a container for one or more threads - just like a win32 window didn't by itself do any processing: Each message handling procedure did.
It could have been modeled as an event/message - the main difference is that the thread model allows the thread to have its local data across those waits. In an event model, a 'windows'/process maintains a data structure which is modified by micro-operations (i.e. individual event procedures) completing in finite time (conceptually: zero time). There is never any deadlock, never any wait for someone else to complete so the data structure is 'released'; no data is ever 'reserved'. The FSM may indicate that in a given state, a given event is illegal and should be treated as an error, but that never causes a deadlock.
You could think of the classical processing of an event as a one-shot thread: It is fired up, does its job (in an atomic manner) and terminates. Introducing the pausing of a thread midway, doing more than an atomic micro-operation, caused threads to grow fat. When lots of data were hidden inside threads, many threads were packed into one process, so that they grew fat, frequently encompassing the entire application. In win32, you would leave one data structure to one 'window', as an FSM of one data structure (say, the state info for protocol), making more 'windows' for other data structures. Your application would be organized as a number of cooperating FSMs, or 'windows', the way networking people have been doing for ages.
I never saw an introductory college textbook promoting this design philosophy (not even in the days of classic Mac OS and win32) - you would learn it only in advanced, telecom oriented courses, long after your basic approach to programming has been molded into the multiple-thread and locked-up data structures way of thinking.
So the FSM / event concepts were lost. And few people are aware of what was lost; they never knew that it existed.
|
|
|
|
|
How long ago do you define "original"? I was doing multithreaded apps (not just events or multitasking) in VB6 back in the last half of the 1990s in Windows. C++ developers were writing multithreaded apps even earlier.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
