On May 04, 2007, at 03:28 UTC, Peter K. Stys wrote: > Here's another thing I don't understand: I wrote a mock plugin that > runs a very long loop. I call the plugin from an RB thread, and the > whole app is tied up for the duration of the loop: if a plugin fn is > called from an RB thread, shouldn't it be "threaded" ie should > control not return to the main app right away?
No, RB threads are cooperative, and your plugin wasn't cooperating. It needs to call RBYieldToAnyThread. See the LongProcessor example that comes with the plugin SDK. > Actitvity Monitor shows 2 threads running, so why the beach ball? > Aren't OS X threads pre-emptive (if I understand the term correctly). Yes, but those have nothing to do with RB threads. > What do I do to "unlock" my app, call app.DoEvents equivalent in my > plugin (eg WaitNextEvent or some such, and then be faced with the > same problem we're discussing all along?). Not WNE; see above. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Strout Custom Solutions _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
