On Feb 12, 2008 10:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:

Btw, this problem concerns not only OpenGL canvas implementation.
Even with bitblt, some operations are not thread-safe.
And in general, what mechanisms you planning to add to SecureSqueak to
guarantee that some code will get exclusive access to functions of
some device?

For instance, try:
10 timesRepeat: [
[ Smalltalk logChange: 'say goodbye to' , 1 seconds asDelay wait
asString, ' your .changes file' ] fork.
]

The above is much more effectively achieved by starting up an image twice and saving code in each :-).

I'll have to handle each situation as I find them. Generally, I'd have to make sure all APIs are thread safe. Also, remember that with Namespaces, an object only has access to a very limited set of other objects (in theory at least).

In the specific case of Canvas, I'll be using something which I still have to give a good name to -- maybe Gate, Proxy, Interface, or Valve or something. It will be an object that implements the public sub-set of Canvas's methods and forwards messages on for a particular clipping Rectangle on that Canvas. When permission to that Canvas is no longer required, the connection is broken and that Valve/Gate/Interface becomes useless. I'm sure E-lang has a good name for these; its a pattern from programming with capabilities.