This is NXPing-in-a-thread in view mode; [Up]
Date: Sun 25-Mar-1991 21:29:05 From: jrscs@uno.edu Subject: NXPing() in a thread 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. ( The NXPing() inside the detached thread ( supposedly ) coordinates the highlighting of a word in a window with the pronunciation of that word. ) Is there some reason why NXPing() can't be called as described above. If so, does anyone know another way of synchronizing things? Thanks, John
Date: Sun 26-Mar-1991 03:35:31 From: wiml@milton.u.washington.edu (William Lewis) Subject: Re: NXPing() in a thread 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 ...
Date: Sun 26-Mar-1991 19:41:30 From: sstreep@next.com (Sam Streeper) Subject: Re: NXPing() in a thread 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?
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.