At 1:00 PM +1100 11/18/02, Iain 'Spoon' Truskett wrote:
Well, the problem is shared data.* Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]:[...]Perl's standard threading behaviour's going to be rather heavyweight, though.Silly question time: Why is it going to be rather heavyweight? (Not complaining or berating, just wanting information =) )
Firing off multiple interpreters isn't that big a deal, though there is some overhead in initializing an interpreter. If we do Clever Things, we can cut down the overhead, but there's still some, so creating a new interpreter will not be dirt cheap. (Which is fine, as it makes the common case faster)
The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up.
The threading model that perl leans towards is either a share-lots scheme, or a share-nothing-but-copy scheme, both of which are pretty expensive. The copy form, of course, requires copying data, which isn't cheap. The share scheme requires lots of locking, as the core data structures are too big for low-level atomic access.
Why? It's not perl's problem space. To do efficient large-scale multithreading you need a shared-nothing system with fast message passing and very little information being sent between threads.> (Though the presentation on Erlang at LL2 has got me thinking moreabout efficient multithreading.Good!I don't think we'll be able to use it for perl, though)Not so good! =)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
