FW: Another personality for a smaller Squeak (was Re: Classical A
pplications (was Re: 17 new updates))
Peter Crowther
Peter.Crowther at it-iq.com
Thu Feb 18 12:47:34 UTC 1999
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
More information about the Squeak-dev
mailing list
|