Richard Frith-Macdonald wrote:

On Tuesday, April 1, 2003, at 04:14 pm, David Ayers wrote:

Ahh, just found it, mad a typo in my find/grep. Note that this method executes in the defaultThread. Therefore the gui might need to assert that its also setup in the default thread.

Good point. I really think it should.

Alexander Malmberg wrote:


Index: Source/NSApplication.m
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSApplication.m,v
retrieving revision 1.234
diff -u -r1.234 NSApplication.m
--- Source/NSApplication.m      19 Mar 2003 16:15:44 -0000      1.234
+++ Source/NSApplication.m      1 Apr 2003 12:45:06 -0000
@@ -72,6 +72,9 @@
#include <AppKit/GSGuiPrivate.h>
#include <AppKit/GSInfoPanel.h>

+/* The -gui thread. See the comment in initialize_gnustep_backend. */
+NSThread *GSAppKitThread;
+
/*
 * Base library exception handler
 */
@@ -156,6 +159,14 @@
  if (first)
    {
      Class backend;
+
+      /*
+      Remember which thread we are running in. This thread will be the
+      -gui thread, ie. the only thread that may do any rendering. With
+      the exception of a few methods explicitly marked as thread-safe,
+      other threads should not do call any methods in -gui.
+      */
+      GSAppKitThread = [NSThread currentThread];

      first = 0;
#ifdef BACKEND_BUNDLE

I couldn't a way to really assert this, but instread of assuming that initialize_gnustep_backend() is called from the default thread, maybe a helper method which sets the the currentThread to the default thread could be invoked here by using performSelectorOnMainThread:withObject:waitUntilDone:

Cheers,
Dave





_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep

Reply via email to