Ensuring canvas safety (using canvas by multiple processes)
Michael van der Gulik
mikevdg at gmail.com
Tue Feb 12 10:03:18 UTC 2008
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev