bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recent drawing optimizations


From: David Ayers
Subject: Re: Recent drawing optimizations
Date: Tue, 01 Apr 2003 16:54:03 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Ludovic Marcotte wrote:

However, for the GNUMail problems, this is only a workaround. GNUMail is
not supposed to make any of these calls in anything except the main
thread,

It doesn't do any of these calls except in the main thread. The subthread post distributed notifications when it wants to update the status label or uses a NSConnection to the main thread to ask for passwords (prompting the password panel), showing error (using alert panels) and stuff.

so the root cause is that something is being run in the wrong
thread. I haven't looked closely at this, though, since I've been unable
to reproduce it. Ludovic?

The stack trace Benhur posted shows where the crash is initiated. The subthread in GNUMail post a distributed notification to update the status label in the MailWindow. The MailWindowController adds itself as an observer in the main thread for those distributed notifications (GNUMailStatusLabelMessage). Upon reception of distributed notifications, this will call, in the main thread, MailWindowController: -updateStatusLabelWithMessage:.

This used to work perfectly for months. I haven't changed anything lately related to that.
Here's my quick shot at this:

I believe the distributed notification center probably doesn't know anything about threads. Any thread running a runloop can probably receive and process distributed notifications. In a mutli threaded App it would be the responsiblity of the method invoked by notification center to make sure it runs in the correct thread by forwarding it to a proxy for the intended thread, if it doesn't happen to be that thread itself.

Cheers,
Dave







reply via email to

[Prev in Thread] Current Thread [Next in Thread]