In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

>> That is not true, you just don't know what you are talking about!
>
> It is true. The official version with GUI has the problem, the command
> line version and MacMegaPOV do not. The problem is definitely not in the
> core code, I don't see how you can seriously claim otherwise.

It is the priority setting of the OS for GUI applications.  Grap too much
and you see a beachball.  Command-line versions don't have a user interface
to serve, thus their priorities are handled very differently.  The only
working way around the beachball is to use MP threads *and* pure Carbon
Events.  Sadly that is easier said than done because Carbon Events replace
WaitNextEvent in a manner that isn't in every respect compatible with object
oriented applications:

Due to the need of "timers" and their callback functions which can end up
being called while your object is half-destroyed.  To be precise, you have
to install and remove timer callbacks in the highest derived class because
otherwise (that is in the lowest common base class that needs the timer,
i.e. a "window" base class) while being in a destructor the timer can fire
and the high-level object parts (i.e. "textwindow") are already destroyed
but the timer has not been disabled in the base class yet (because the
destructor function of "window" hasn't been called yet).  This makes using
Carbon Events a bit more tricky than they should be, and that is why many
applications don't use them (the Finder doesn't fully use them as well, it
seems)...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message