On Tuesday, September 28, 1999 12:30 PM, Stephen Pair [SMTP:spair@advantive.com] wrote:
Not that I am aware. Making Smalltalk multi-threaded is tricky. Some Smalltalks have taken the approach of making the "Process" concept in Smalltalk equate one-for-one with OS threads. I think that approach is very bad. First, it's difficult to implement, and second, it's inefficient because you have the additional overhead of the OS context switching.
Elliot Miranda on c.l.s. a while back also pointed out that this make the VM's scheduling behavior dependant on the OS, and makes it unreproducable.
From Elliot Miranda at : http://www.dejanews.com/%5BST_rn=ps%5D/getdoc.xp?AN=387224637 On a side-note related to reliability, I belive Java has saddled itself with a real albatross in being natively multi-threaded. A natively multi-threaded VM *isn't* repeatable, period. And that means its *very* difficult to debug VM bugs.
It's kind of nice knowing that context switching can occur only at well defined points. In Squeak, that would be
Interpreter >># checkForInterrupts
I like Travis' idea of mapping OS threads to Smalltalk ProcessSchedulers.
Hmmm.
[RelativelyLongIndepentantTask startUp] forkOn: ProcessScheduer new.
Also, there was a book a while ago on Concurrent Smalltalk. It was pretty interesting.
http://www.amazon.com/exec/obidos/ASIN/9810201125/onlinetoday/
ISBN: 9810201125 Design and Implementation of Concurrent Smalltalk (World Scientific Series in Computer Science, Vol 21) by Yasuhiko Yokote
squeak-dev@lists.squeakfoundation.org