in reply to Re^4: RFC: Implicit Parallelization Pragma
in thread RFC: Implicit Parallelization Pragma
Well, while being an interesting part of Win32 API I've never seen before, fibers ultimately don't do anything towards the original article topic. My phrase on the process managing its own threads was probably not worded well.
I've seen Sun papers on their research of async CPUs and it looks mighty interesting. Essentially, they view the CPU as a farm of really tiny specialized units, which are not synchronized to a single clock signal. As I understood, a processing thread (either a separate process, or whatever) can lock, say, the ALU for 5ns to do a division, while two other threads do memory loads (each being, say, 2ns). Anywho, it's supposed to be different from Pentium's way of parallellizing instructions in that there is no central clock pulse that everything marches to. Interesting stuff...
Now, if the OS supports hundreds of thousands of threads and is run on a big soup of such asynchronous CPU tidbits, there is possibility for micro-threading. At that stage, yes, the interpreter would do very well by being able to very quickly allocate and tear down these tiny parallel tasks automatically.