On Sat, 03 Jan 2004 01:48:07 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote: > ding! ding! ding! you just brought in a cpu specific instruction which > is not guaranteed to be on any other arch. in fact many have such a > beast but again, it is not accessible from c.
> you can't bring x86 centrism into this. the fact that redmond/intel > threads can make use of this instruction to do 'critical sections' is a > major point why it is bad for a portable system with many architectures > to be supported. > i disagree. it is covered for the intel case only and that is not good > enough. > again, intel specific and it has to be tossed out. > but atomic operations are not available on all platforms. > not in a unix environment. real multi-threaded processes already have > this problem. > that is a kernel issue and most signalling systems don't have thread > specific arguments AFAIK. > virtual ram is what counts on unix. you can't request some large amount > without using real swap space. > again, redmond specific. > what win32 does is not portable and not useful at a VM level. > ok, i can see where you got the test/set and yield stuff from now.... > finally, it is redmond specific again and very unportable. i > have never heard of this fibre concept on any unix flavor. > and that is not possible on other platforms. > that is a big point and one that i don't see as possible. redmond can do > what they want with their kernel and user procs. parrot can only use > kernel concepts that are reasonably portable across most platforms. > kernel threads are reasonably portable (FSDO of reasonable) but anything > beyond that such as fibres, test/set in user space, etc is not. locks > have to be in kernel space since we can do a fibre yield in user space > on any other platform. so this rule out user space test/set as well > since that would need a thread to spin instead of blocking. > > your ideas make sense but only on redmond/intel which is not the target > space for parrot. That's pretty much the crux. I don't know what is available (in detail) on other platforms. Hence I needed to express the ideas in terms I understand and explain them sufficiently that they could be viewed, interpreted and either related to similar concepts on othe platforms, or shot down. I accept your overall judgement, though not necessarially all the specifics. Maybe it would be possible (for me + others) to write the core of a win32 specific, threaded VM interpreter that would take parrot byte code and run it. Thereby, utilising all the good stuff that preceeds the VM interpreter, plus probably large chunks of the parrot VM, but provides it with a more native compatible target. That's something that obviously not a simple project and is beyond the scope of this list. Thanks for taking the time to review this. Nigel Sandever.
