My continued experiments in scripting (in this case Mail) have thrown up an interesting issue.
If I get Mail to run an applescript that tells my app about the arrival of some new mail, and then attempt to read this new mail from my application in this call, all sorts of things go wonky.
The most basic failure is that my app fails to 'see' the newly arrived mail when asking Mail. It's as if Mail is not equipped to handle apple events at some times (such as when processing rules), or perhaps this is a more general problem with Apple Events on the Mail process being nested.
The thought had occurred to me while writing the scripting bridge code that it may not be possible to nest an Apple Event connection to a given process inside another connection from that same processes - though I was not able to find any documentation that explicitly told me NOT to do this.
Aside from simply not being able to query Mail as I'd expect, I've experienced a range of other nasties that may be related, including:
1. Apparent lock-ups of my app (but not every time)
2. ...inability to stop the app as a debuggee within XCode
3. ...and (after 2) a full kernel panic
The fix seems to be to avoid the nesting. Simply 'step out of the way' of the original Apple Event from Mail and let it complete before sending any messages the other way on a completely different stack (i.e. 'later').
I'm pretty sure the kernel panic was due to a combination of sitting on a break point while handling the Apple Event from the Mail process, then (possibly after some time-out), attempting to kill the debuggee while some low-level IPC code thought some resources were still being locked between the two processes.
It would seem more likely that the problem I'm experiencing would be an issue with the internal state of Mail at the time it processes mail rules, rather than a general problem nesting Apple Events between processes (which seems rather fundamental for a general IPC mechanism). As a newbie, I need to do some more research...