| From: | Duane McDonnell |
| Date: | 14 Dec 99 at 02:54:03 |
| Subject: | Re: Re: Multithreading + gfx cards |
From: Duane McDonnell <dmcdonnell@primus.com.au>
>From: Nicholas Clarke <nclarke@diku.dk>
>On Mon, 13 Dec 1999, Ilkka Lehtoranta wrote:
>> From: Ilkka Lehtoranta <iti@solutions.fi>
>> AO>> I had trouble just with "Text" functions writing to the maintask's
>> AO>> rastport. It crashed randomly, at the finish, I simply used
>> AO>> my sub task to fill a buffer with the ascii then Signal() the main
>> AO>> task to render it...
>> AO>
>> AO> This sounds weird. Few OS structures contain e.g. a message port, and
is
>> AO> therefor bound to a certain task - but everybody can render to a
>> AO> rastport, so I'm quite sure something else was wrong with your program.
>>
>> AFAIR you have to duplicate a rastport if you are renderining to the
>> rastport
>> from other processes... Although I couldn't verify this from autodocs or
>> RKM I recall this is mentioned somewhere in RKM (???)...
>Never ever use the same rastport to render from different processes. I
>found out the hard way years ago that this is a really bad idea.
It's quite safe to do this for layered RastPorts. That's how Intuition
plonks menus, requesters and gadget image transitions etc. onto RastPorts
even though other tasks may have allocated/initialized them. Rendering
functions should do a LockLayerRom() if the RastPort has a Layer
associated with it. The lock effectively sets up semaphore protection
making multi-threaded rendering quite safe.
Non-layered RastPorts are the ones that cause all the grief, these are
better confined to single threaded accesses although you can certainly
make them safe for multi-threaded use if you really need to. You
probably don't though, it's a misconception that the more threads
you can have hurtling data at a RastPort the faster the update,
they actually have to wait for the previous guy to finish.