Ensuring canvas safety (using canvas by multiple processes)

Michael van der Gulik mikevdg at gmail.com
Tue Feb 12 09:54:07 UTC 2008


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

> On 12/02/2008, Michael van der Gulik <mikevdg at gmail.com> wrote:
> >
> >
> > Lots, but it depends on what the problem actually is. Could you describe
> it
> > in more detail?
> >
> well, when you issuing a command like:
>
> canvas translateBy: offset during: [ ... ].
>
> canvas does following:
>
> gl pushMatrix.
> gl translateBy: offset.
> aBlock value.
> gl popMatrix.
>
> operations with matrix affecting global state, if you try to draw
> anything in parallel process, while in current process you evaluating
> a block, you will be screwed up.
>
> Another issue is with using glBegin/glEnd pair. These commands can't
> be nested, also a number of valid GL operations inside glBegin/glEnd
> are limited.
>
> In general, any code, that doing like:
>
> gl changeSomeState.
> ..some code..
> gl revertToPreviousState.
>
> is potentially leading to nirvana, if you can't guarantee a proper
> order of commands, issued to OpenGL.
>


I thought being in nirvana was meant to be a good thing?

Anyway, I understand what you mean now. This looks like an implementation
issue of your canvas, so the thread protection should be encapsulated inside
it.

I.e.

myMutex critical: [
    gl changeSomeState.
    ..some code..
    gl revertToPreviousState.
].

Just make sure that you keep the critical sections as small as possible, and
don't call any outside code (including blocks).

I don't think there is a large speed issue here by using Semaphores. If you
are worried about speed, you could have two canvases: a reentrant one and a
non-reentrant one. Somehow they could reuse code, but I'll leave this as an
exercise for you.

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/9df835f4/attachment.htm


More information about the Squeak-dev mailing list