First I would like to point out this mailing list if for discussions about WebKit internal development. There is webkitsdk-dev@lists.apple.com for discussions about development of applications/widgets using WebKit. You might have more exposure there.

Simply locking around WebKit's WebView wont solve this problem. The reason is you don't know what other Cocoa classes or System APIs WebKit uses that aren't thread safe. Most Cocoa classes are publicly listed as not thread safe.

There is a list of thread safe classes and other information here:

http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/articles/CocoaSafety.html

You might want to rethink your design, calling WebKit from only the main thread. This will save you many headaches. Most of WebKit's API is non-blocking and callback/delegate based, so threads really aren't needed.

— Timothy Hatcher » colloquy.info

On Jul 10, 2005, at 7:51 PM, Ben Kazez wrote:

In fact, I am calling WebKit APIs from multiple threads, which wasn't a good idea on my part. This is my first experience with multiple threads, and I'm enjoying it but am still quite a novice. My only WebKit call is to [WebView -stringByEvaluatingJavaScriptFromString:], so I've changed it to

[_webViewLock lock];
[_webView stringByEvaluatingJavaScriptFromString:endHandlerJavaScript];
[_webViewLock unlock];

where _webViewLock is an instance variable in the Dashboard plugin object. However, the crash still happens -- some elements too tall, others too short, elements disappearing until you mouse over them, and then EXC_BAD_ACCESS. Should my locking code above have worked? (I can move this discussion to Cocoa-dev if it becomes off-topic for this list.)

Thank you very much for your help.