On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: > On Sun, Apr 24, 2005 at 03:37:23AM +0000, Nigel Sandever wrote: > : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: > : > > : > Oh well. At least the same code can be salvaged to make iThreads > : > : Please. No iThreads behaviour in Perl 6. > : > : Nobody uses them and whilst stable, the implementation is broken in so many way. > : > : But worse, the underlying semantics are completely and utterly wrong. > > Are you confusing iThreads with pThreads? Or are you recommending we > go back to the pThreads fiasco? >
I certainly am not advocating a shared-by-default, or everything-shared model. > > From what I've read, the trend in most modern implementations of > concurrency is away from shared state by default, essentially because > shared memory simply doesn't scale up well enough in hardware, and > coordinating shared state is not terribly efficient without shared > memory. If you are claiming that modern computer scientists are > completely and utterly wrong in moving that direction, well, that's > your privilege. But you should be prepared for a little pushback > on that subject, especially as you are merely badmouthing something > without goodmouthing something else in it's place. > When I said "iThreads", I was referring to the only defenition I can find for iThreads, the Perl 5.8.x implementation. The "broken underlying semantics" are 1) The fork-like, "duplicate-everything-in-the-process-at-the-point-of-spawn". This makes spawning a thread heavier than starting a process in many cases. It makes using (the p5 implementation of) iThreads an exercise in frustration trying to avoid the semantics it imposes. 2) The shared-memory is really multiple-copies-with-ties. This removes 90% of the benefits of shared-memory, whilst doing nothing to make it easier to use. The user is still responsible for locking and synchronisation, but looses the ability to use either ties or object-semantics to encapsulate it. That forces every programmer to re-invent the techniques in every program as it is nearly impossible to write clean, effcient apis and put them into modules. The duplication and tied-updates makes using shared memory so slow and clumsy, that it can be quicker to freeze/transmit-via-socket/thaw shared data between processes, than to share a piece of memory within a process. 3) Using the low-level pthreads api as the basis for the user view of threading. This precludes the use of native thread features on any platform that has extended or better api, and forces the programmer to deal with the ultra-low- level at which that API is defined without any of the control that he would have if using it directly. > Larry njs.
