🚀 go-pugleaf

In article <1992Sep30.130539.12174@ghost.dsi.unimi.it> rizzi@ghost.dsi.unimi.it (daniele rizzi) writes:
>
>
>Hi all,
>I'm trying to build an application with two concurrent c_threads, the former
> managing the windows, the latter working with the DSP56.
>I would like that the secondary thread shows the result of its computation
>to the main window, so in the 'c' code I have inserted the method:
>
>[form setIntValue:the_result];
>
>at runtime, sometimes the program crashes with 'Unlock the Wrong View' message
>and various DPS-errors. Why?

Doing anything with the windowserver from any thread other than the
main one can cause weird things to happen --- only send messages to
AppKit objects and do things with the windowserver from the main
thread.

A solution is to either use conditions or muticies to signal the
main-thread that it's time to display a certain shared variable or
pass mach-messages to the main thread.  Check out the Sorting in
Action miniexample for details on using speaker-listener.


andrew
-- 
andrew@cubetech.com     | "We shall not cease from exploration
Andrew Loewenstern      |  And the end of our exploring
Cube Technologies, Inc. |  Will be to arrive where we started
                        |  And know the place for the first time." -T.S. Eliot

rizzi@ghost.dsi.unimi.it (daniele rizzi) writes:
> I'm trying to build an application with two concurrent c_threads, the former
>  managing the windows, the latter working with the DSP56.
> I would like that the secondary thread shows the result of its computation
> to the main window, so in the 'c' code I have inserted the method:
> 
> [form setIntValue:the_result];
> 
> at runtime, sometimes the program crashes with 'Unlock the 
> Wrong View' message and various DPS-errors. Why?

The application kit isn't thread safe; you can only use it from one thread.   
When the first thread is in the application kit and the second thread  
interrupts and uses the kit, you are hosed.  In 3.0, a good solution is to use  
Distributed objects; publish a "communication handling object" from the main  
thread that responds to messages by drawing things (like your setIntValue  
message) and run that object's connection from the appkit.  Then, when "remote"  
messages are received over that connection, they are dispatched from the main  
thread (from DPS client, actually).  Other threads can safely connect to this  
object and send messages that will be received in the main thread.

Just for fun, here's what the doc says about thread safety and various parts of  
the system.  It says that Objective-C runtime isn't thread safe; though this is  
technically true, it's only vulnerable while growing selector caches, and since  
they double in size each time they grow, it gets less unsafe over time...
----------------------------
Many of the functions and methods provided by NeXTSTEP weren't designed with  
multithreaded applications in mind.  As a result, they might not work correctly  
when called simultaneously by two or more of your application's threads.  (A  
function or method that can safely be called by more than one thread at once is  
thread-safe.)  In general, unless you know that a function or method is  
thread-safe, you should assume that it isn't. 

The following are thread-safe:

 	Distributed Objects, which is described in the General Reference
 	Mach functions (except for mach_error())
 	UNIX system calls (you should use cthread_errno() instead of errno)
 	NeXTSTEP exception handling (for example, NX_RAISE())
 	The malloc() function and its related functions, though their thread  
safety can be disabled by calling malloc_singlethreaded() (which in general  
should not be done)

The Objective C runtime system is not thread-safe by default.  To make it  
thread-safe, use the function objc_setMultithreaded().  

The following are not thread-safe:

 	The Application Kit (messages to kit objects should be sent only from  
the main thread) 
 	DPS client routines 
 	The Window Server (drawing should be done only from the main thread)
 	Standard I/O functions, such as printf()
 	Most of the functions in the libc library

-sam

--
Opinions expressed herein are not those of my employer.  They're not even
mine.  They're probably wrong besides.  How did they get in here, anyway?