Is a SkyHook Safe[Re: Is Set growth thread-safe?]

jwalsh at bigpond.net.au jwalsh at bigpond.net.au
Fri Sep 23 00:06:34 UTC 2005


Sorry for the rude subject line.

Most may not know what a SkyHook is, and for those who don't, it is a joke.
There is a limit to the number of "work-arounds", even for Smalltalk.
Smalltalk is simply not designed for it. [yet].

Ref:
http://en.wikipedia.org/wiki/RISC  >  RISC: Definition and Much More From Answers.com :

I think the above definition is not bad and will a serve as a solid Principle upon which to build anArgument:

1. Smalltalk as an IDE should not need to call upon extranious program support, unless  it respects the rules of Smalltalk. That is why it is called IDE.
2. The Smalltalk problems are ALL introduced ones.
3. Smalltalk demands the "Software be Designed First and Programmed Later".

If the intended Application Software Design, prior to coding Smalltalk (or any other language for that matter), were given the same RISC teatment  in software, as in RISC  hardware, then we'd have less RISK.
Furthermore, I sugget, many of the tactics provided so far ,  would be unecessary.

What say you?


---- Bert Freudenberg <bert at impara.de> wrote: 
> Am 22.09.2005 um 20:43 schrieb Ross Boylan:
> >
> > By the usual logic of
> > providing thread-safety around classes as needed, wouldn't it be
> > better for Object, Model, and EventModel to protect the update
> > mechanisms appropriately?
> 
> No, because those mechanisms are intended to be used from the main UI  
> thread. You should not send "changed" messages from a non-UI process,  
> because they are handled synchronously (sending "update" messages  
> etc). You need to asynchronously let the UI process know it should act.
> 
> There are several ways to accomplish this. A commonly used one in  
> Morphic is this:
> 
>      WorldState addDeferredUIMessage: [...]
> 
> You can call this from a background process, the block will later be  
> executed in the UI process. Internally, it uses a SharedQueue holding  
> the blocks.
> 
> - Bert -
> 
> 




More information about the Squeak-dev mailing list