This got eaten first time around as I've changed mail addresses... here we
go again.

		- Peter

> -----Original Message-----
> From:	Peter Crowther 
> Sent:	Friday, February 12, 1999 8:34 AM
> To:	'squeak at cs.uiuc.edu'
> Subject:	RE: Another personality for a smaller Squeak (was Re:
> Classical Applications (was Re: 17 new updates))
> 
> I like this. But it sounds like we need some threading support to do this
> effectively.
> I think threading to be an important addition to Squeak.
> 
> Processes are already built-in; I can already run a large number of
> virtual sessions interacting with a Smalltalk image at one time (tested
> with 20 sending text messages; didn't even get my P200 to 10% CPU).
> However, the existing (certainly with MVC) interface framework is not
> particularly process-friendly, and I'm working on getting things like
> Debuggers at least to schedule and display as they pop up from a
> background thread, pending allowing remote debugging across a Web
> interface.  Threading is already here!
> 
> However, as a conversation on the list pointed out about a month ago,
> threads mean synchronisation and sync overhead even when only one thread
> is running.  Lightweight synchronisation isn't easy, especially with the
> very fine-grained objects found in most Smalltalks; I'm sure I still have
> a large number of race conditions in my code, although the main culprits
> have been replaced with ThreadSafeDictionaries, etc..  I really wouldn't
> want to bloat the run-time environment by putting image-level
> synchronisation in for everything.  It would run like a pig on stilts.
> 
> Yes, threading is good, in its place, but you have to consider the
> overheads as well and decide whether the cost is worth paying.  For a
> windowed GUI, check out the way VisualWorks does it [or did last I looked
> about 3 years ago].  There's still a single interface process, just
> multiple windows.  If (*if*) I were going to change the way the interface
> worked to support multiple windows, I'd go their way: have a Launcher that
> replaces the background menu, and a ScheduledWindow (or similar) that
> knows how to create and display itself on-screen.  But it then gets much
> harder to do interface experiments, and experimentation is one very strong
> point with Squeak at the moment.
> 
> 		- Peter