wiml@milton.u.washington.edu (William Lewis) (03/26/91)
I've changed the Newsgroups: line, as the query isn't really relevant to Objective-C ... In article <00946246.F502A0C0@uno.edu> jrscs@uno.edu writes: > I have a question on the use of NXPing() in a detached thread. The >detached thread processes some sound data while the "main" thread handles >the user interface. NXPing() works fine inside the main thread but it >hangs my NeXT if it call it inside the method for which the thread was >launched. I can't imagine how it would hang the whole NeXT, but I can see how it could hang your application without much trouble. The trouble stems from the fact that the DPS routines (in fact, almost all library routines that change any sort of global state, including seemingly safe ones as close()/open()) are not reentrant; they're not designed for a multi-threaded environment. So when you call NXPing() in a subsidiary thread, the main thread is probably sitting in DPSGetEvent() (assuming it's a normal Appkit-using application), and both threads attempt to interact with the window server simultaneously, with undesirable results. > ( The NXPing() inside the detached thread ( supposedly ) >coordinates the highlighting of a word in a window with the pronunciation >of that word. ) It would be really nice if the DPS*() routines _were_ reentrant (or at least used mutexes or something... hello NeXT?) As far as I know, the only way to do this is to send a Mach message to a port registered via DPSAddPort(), which will wake up the main thread; the handler on that port can then NXPing() or do other arbitrary processing. Unfortunately this seems like a whole lot more trouble than it should be ... -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "Just remember, wherever you go ... you're stuck there."
sstreep@next.com (Sam Streeper) (03/27/91)
In article <19044@milton.u.washington.edu> wiml@milton.u.washington.edu (William Lewis) writes: >In article <00946246.F502A0C0@uno.edu> jrscs@uno.edu writes: >> I have a question on the use of NXPing() in a detached thread. The >>detached thread processes some sound data while the "main" thread handles >>the user interface. NXPing() works fine inside the main thread but it >>hangs my NeXT if it call it inside the method for which the thread was >>launched. > > I can't imagine how it would hang the whole NeXT, but I can see how >it could hang your application without much trouble. The trouble Remember every app is a client of the Window Server. If you violate the window server by entering from multiple threads, everybody loses. >multi-threaded environment. So when you call NXPing() in a subsidiary >thread, the main thread is probably sitting in DPSGetEvent() (assuming >it's a normal Appkit-using application), and both threads attempt to >interact with the window server simultaneously, with undesirable results. Exactly. >As far as I >know, the only way to do this is to send a Mach message to a port >registered via DPSAddPort(), which will wake up the main thread; the >handler on that port can then NXPing() or do other arbitrary This is a good solution. For a code example similar to this, see /NextDeveloper/Examples/SortingInAction -sam Opinions are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway? -- Opinions are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway?