On Feb 12, 2008 10:38 PM, Igor Stasenko <siguctua at 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.

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080212/67bfb7b9/attachment.htm