May 2006 - Darwin-dev - lists.apple.com

How to use VARIANT Structure of C on MAC OSX and XCODE 2.2...............
by Gaurav Kumar 08 May '06

08 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcZxTFh/3khFwMwIRYKyrhR99sFZBw== _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: question for CFRunLoopStop()
by Kevin Van Vechten 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 5, 2006, at 12:20 PM, Philip Lukidis wrote: CFRunLoopStop(), however, does implicitly call CFRunLoopWakeUp(). - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Perhaps I am missing something, but removing/invalidating the timer from the child runloop does not always provoke the child thread to exit. So after having read your reply, I suppose that the best way to solve my problem would be to stop the runloop. But the documentation says that removing all sources from a runloop causes CFRunLoopRun() to return: "The current thread's run loop runs in the default mode (see "Default Run Loop Mode") until the run loop is stopped with CFRunLoopStop or all the sources and timers are removed from the default run loop mode." Looking at the CF sources, it appears that CFRunLoopTimerInvalidate() calls CFRunLoopRemoveTimer() to remove the timer from its runloop in all modes that it's registered in. However, I do not consistently find that this is true in my case. Perhaps there is a fault in my code, but invalidating the timer does not always cause the child thread to exit (and according to the docs, invalidating a timer removes it from the runloop). However, so far CFRunLoopStop() consistently works. Offhand could you explain this? While the runloop is waiting for events, it is blocked on a mach port read. The only way to unblock it is for a timer to fire, a source to be signaled, or to call CFRunLoopWakeUp() from another thread. The documentation suggests that removing or invalidating the last source would stop the runloop (ostensibly via a call to CFRunLoopWakeUp()). However, looking at the source verifies your findings, namely that CFRunLoopWakeUp() is not called implicitly as part of the CFRunLoopTimerInvalidate() or CFRunLoopRemoveTimer() calls. Seems like you can either continue calling CFRunLoopStop(), or you can manually call CFRunLoopWakeUp() after removing/invalidating the timer. This email sent to site_archiver(a)lists.apple.com

1 0

RE: question for CFRunLoopStop()
by Philip Lukidis 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcZwfh5fEca789+oTz+r1u+MCYYykgACKNVg Thread-topic: question for CFRunLoopStop() Thanks for your help in this matter. Using this approach seems to work fine. Philip Lukidis -----Original Message----- From: Kevin Van Vechten [mailto:kevin@opendarwin.org] Sent: Friday, May 05, 2006 3:55 PM To: Philip Lukidis Cc: Darwin development list Subject: Re: question for CFRunLoopStop() The parent thread needs to retain the child's runloop to ensure it has a valid reference when the call to CFRunLoopStop is made. You'll need to do some synchronization around the hand-off of the runloop reference from child to parent to ensure correctness. If properly retained, the run loop reference should remain valid after the child thread exits. - Kevin On May 5, 2006, at 11:36 AM, Philip Lukidis wrote: > I forgot to mention the symptoms to my problem. The problem > followed the scenario laid out in the case of the parent thread > running down the child thread, which had a timer on its runloop. > Sometimes the child "timer thread" had exited by the time the > parent called CFRunLoopStop() was (so the parent was scribbling in > random memory, as the runloop was deallocated). But I figured out > the parent was provoking the child to exit by removing the timer > from the runloop, so there was an actual race condition here. > > Would it be better for the parent to remove the timer from the > loop, or call CFRunLoopStop()? > > thanks, > > Philip Lukidis > > -----Original Message----- > From: darwin-dev-bounces+plukidis=guillemot.com(a)lists.apple.com > [mailto:darwin-dev-bounces+plukidis=guillemot.com@lists.apple.com]On > Behalf Of Philip Lukidis > Sent: Friday, May 05, 2006 11:47 AM > To: darwin-dev(a)lists.apple.com > Subject: question for CFRunLoopStop() > > > Hello. I hope that I'm posting this to the correct list. > > Concerning CF, I was wondering if the following scenario is correct: > A "parent" thread creates a child thread via the pthread library. > The child thread has only 1 runloop source on it (a timer in fact), > and once the timer is applied onto the child runloop by the child > itself, the child proceeds to call CFRunLoopRun() on itself. Now > the parent is responsible for running down this child on demand. > Can the parent rundown the child by: > -invalidating the timer (via CFRunLoopTimerInvalidate()) > -removing the timer (via CFRunLoopRemoveTimer()) > -calling CFRunLoopIsWaiting() in a while loop until it returns > true (which indicates that all callbacks have drained and that it > is waiting again, but of course since the timer was invalidated it > can never be called again). Of course I should NOT holding a > resource which the callback might need in order to execute and exit. > -calling CFRunLoopStop() > -calling pthread_join() on the pthread > > Can this also be extended to other runloop sources, by using > CFRunLoopSourceInvalidate() instead of CFRunLoopTimerInvalidate(), > and CFRunLoopRemoveSource() instead of CFRunLoopRemoveTimer()? > > If these procedures are incorrect, why so, and what are the > alternatives? > > thanks, > > Philip Lukidis > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/plukidis% > 40guillemot.com > > This email sent to plukidis(a)guillemot.com > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/kevin% > 40opendarwin.org > > This email sent to kevin(a)opendarwin.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: compile for i86 on my PPC?
by Eric Albert 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hope this helps, Eric On May 5, 2006, at 1:12 PM, Kevin Van Vechten wrote: Yes, you can use the -arch argument with gcc or g++, i.e.: g++ -arch i386 -arch ppc -arch ppc64 ... Will build for all three architectures. For more details: <http://developer.apple.com/technotes/tn2005/tn2137.html> - Kevin On May 5, 2006, at 1:05 PM, Paul Archibald wrote: Here is part of my makefile: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Specifically, you'll want to pass the -arch flags and -isysroot to the compiler, like this: $(TARGET): $(OBJECTS) g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk - o $@ -dynamiclib -install_name $(DESTDIR)/$@ $^ strip -x $@ %.o: %.cpp g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk - c -O2 -o $@ $^ -I /System/Library/Frameworks/JavaVM.framework/Headers You'll need to be sure to build on a system with universal libraries so the link phase will succeed. I don't know whether they encompass JNI, but usually you'll want to use the 10.4u.SDK <http://developer.apple.com/opensource/ buildingopensourceuniversal.html> Our Java app uses a JNI lib for mathematical calculations. We build the JNI with GCC with a makefile. Since we entering the IntelMac age, we need to target our JNIs to both the i86 and PPC architectures. I am doing it now by building the i86 JNI on an intelMini, and the PPC JNI on my PPC powerbook. My question is this: can I build for a different architecture than that of the machine doing the compiling? I would like to be able to build both the PPC and i86 libs on whatever machine I have handy. Is there a g++ option to force which architecture is output? I am not very experienced with makefiles. $(TARGET): $(OBJECTS) g++ -o $@ -dynamiclib -install_name $(DESTDIR)/$@ $^ strip -x $@ %.o: %.cpp g++ -c -O2 -o $@ $^ -I /System/Library/Frameworks/ JavaVM.framework/Headers This email sent to site_archiver(a)lists.apple.com

1 0

Re: compile for i86 on my PPC?
by Justin C. Walker 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 5, 2006, at 13:05 , Paul Archibald wrote: Details are in the documentation and the Xcode mailing list archives. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income -------- When LuteFisk is outlawed, Only outlaws will have LuteFisk -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Our Java app uses a JNI lib for mathematical calculations. We build the JNI with GCC with a makefile. Since we entering the IntelMac age, we need to target our JNIs to both the i86 and PPC architectures. I am doing it now by building the i86 JNI on an intelMini, and the PPC JNI on my PPC powerbook. My question is this: can I build for a different architecture than that of the machine doing the compiling? You can build cross-platform, and in fact, you can produce a single "binary" that will work on both platforms (the so-called "universal" binaries, or the Binaries Previously Known as Fat). You can get full details on Apple's developer website, or in the Xcode documentation that comes with your Mac. The latter may require you to install the developer tools, but since you are a developer, I assume you have already done that :-} There is also a mailing list (see <http://lists.apple.com>) for Xcode-related development questions (there is also an archive for this list). There are (as always) details to be considered (I don't know for sure what sort of cross-platform Java support is available, for example), and the versions of Mac OS X that you have to support also affect how you build (e.g., it's tough to build a universal binary that supports everything from 10.0 to 10.4 on PowerPC and 10.4 on Intel :-}). This email sent to site_archiver(a)lists.apple.com

1 0

Re: compile for i86 on my PPC?
by Kevin Van Vechten 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Yes, you can use the -arch argument with gcc or g++, i.e.: g++ -arch i386 -arch ppc -arch ppc64 ... Will build for all three architectures. For more details: <http://developer.apple.com/technotes/tn2005/tn2137.html> <http://developer.apple.com/opensource/buildingopensourceuniversal.html> - Kevin On May 5, 2006, at 1:05 PM, Paul Archibald wrote: Here is part of my makefile: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… You'll need to be sure to build on a system with universal libraries so the link phase will succeed. I don't know whether they encompass JNI, but usually you'll want to use the 10.4u.SDK Our Java app uses a JNI lib for mathematical calculations. We build the JNI with GCC with a makefile. Since we entering the IntelMac age, we need to target our JNIs to both the i86 and PPC architectures. I am doing it now by building the i86 JNI on an intelMini, and the PPC JNI on my PPC powerbook. My question is this: can I build for a different architecture than that of the machine doing the compiling? I would like to be able to build both the PPC and i86 libs on whatever machine I have handy. Is there a g++ option to force which architecture is output? I am not very experienced with makefiles. $(TARGET): $(OBJECTS) g++ -o $@ -dynamiclib -install_name $(DESTDIR)/$@ $^ strip -x $@ %.o: %.cpp g++ -c -O2 -o $@ $^ -I /System/Library/Frameworks/JavaVM.framework/ Headers This email sent to site_archiver(a)lists.apple.com

1 0

compile for i86 on my PPC?
by Paul Archibald 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Here is part of my makefile: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Our Java app uses a JNI lib for mathematical calculations. We build the JNI with GCC with a makefile. Since we entering the IntelMac age, we need to target our JNIs to both the i86 and PPC architectures. I am doing it now by building the i86 JNI on an intelMini, and the PPC JNI on my PPC powerbook. My question is this: can I build for a different architecture than that of the machine doing the compiling? I would like to be able to build both the PPC and i86 libs on whatever machine I have handy. Is there a g++ option to force which architecture is output? I am not very experienced with makefiles. $(TARGET): $(OBJECTS) g++ -o $@ -dynamiclib -install_name $(DESTDIR)/$@ $^ strip -x $@ %.o: %.cpp g++ -c -O2 -o $@ $^ -I /System/Library/Frameworks/JavaVM.framework/ Headers This email sent to site_archiver(a)lists.apple.com

1 0

Re: question for CFRunLoopStop()
by Kevin Van Vechten 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com - Kevin On May 5, 2006, at 11:36 AM, Philip Lukidis wrote: thanks, Philip Lukidis -----Original Message----- From: darwin-dev-bounces+plukidis=guillemot.com(a)lists.apple.com [mailto:darwin-dev-bounces+plukidis=guillemot.com@lists.apple.com]On Behalf Of Philip Lukidis Sent: Friday, May 05, 2006 11:47 AM To: darwin-dev(a)lists.apple.com Subject: question for CFRunLoopStop() Hello. I hope that I'm posting this to the correct list. thanks, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The parent thread needs to retain the child's runloop to ensure it has a valid reference when the call to CFRunLoopStop is made. You'll need to do some synchronization around the hand-off of the runloop reference from child to parent to ensure correctness. If properly retained, the run loop reference should remain valid after the child thread exits. I forgot to mention the symptoms to my problem. The problem followed the scenario laid out in the case of the parent thread running down the child thread, which had a timer on its runloop. Sometimes the child "timer thread" had exited by the time the parent called CFRunLoopStop() was (so the parent was scribbling in random memory, as the runloop was deallocated). But I figured out the parent was provoking the child to exit by removing the timer from the runloop, so there was an actual race condition here. Would it be better for the parent to remove the timer from the loop, or call CFRunLoopStop()? Concerning CF, I was wondering if the following scenario is correct: A "parent" thread creates a child thread via the pthread library. The child thread has only 1 runloop source on it (a timer in fact), and once the timer is applied onto the child runloop by the child itself, the child proceeds to call CFRunLoopRun() on itself. Now the parent is responsible for running down this child on demand. Can the parent rundown the child by: -invalidating the timer (via CFRunLoopTimerInvalidate()) -removing the timer (via CFRunLoopRemoveTimer()) -calling CFRunLoopIsWaiting() in a while loop until it returns true (which indicates that all callbacks have drained and that it is waiting again, but of course since the timer was invalidated it can never be called again). Of course I should NOT holding a resource which the callback might need in order to execute and exit. -calling CFRunLoopStop() -calling pthread_join() on the pthread Can this also be extended to other runloop sources, by using CFRunLoopSourceInvalidate() instead of CFRunLoopTimerInvalidate(), and CFRunLoopRemoveSource() instead of CFRunLoopRemoveTimer()? If these procedures are incorrect, why so, and what are the alternatives? Philip Lukidis _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/plukidis% 40guillemot.com This email sent to plukidis(a)guillemot.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/kevin% 40opendarwin.org This email sent to kevin(a)opendarwin.org This email sent to site_archiver(a)lists.apple.com

1 0

RE: question for CFRunLoopStop()
by Philip Lukidis 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcZwc3Qjsm5DQbBARYaBkXg3a2f2NwABPsAw Thread-topic: question for CFRunLoopStop() Thanks for your reply. Perhaps I am missing something, but removing/invalidating the timer from the child runloop does not always provoke the child thread to exit. So after having read your reply, I suppose that the best way to solve my problem would be to stop the runloop. But the documentation says that removing all sources from a runloop causes CFRunLoopRun() to return: "The current thread's run loop runs in the default mode (see "Default Run Loop Mode") until the run loop is stopped with CFRunLoopStop or all the sources and timers are removed from the default run loop mode." However, I do not consistently find that this is true in my case. Perhaps there is a fault in my code, but invalidating the timer does not always cause the child thread to exit (and according to the docs, invalidating a timer removes it from the runloop). However, so far CFRunLoopStop() consistently works. Offhand could you explain this? Finally, I was using pthread_join as a precautionary measure only, that is just to make sure that after the child had been ordered to quit, that it had fully exited (and then I could clean up its resources). thanks for your reply, Philip Lukidis -----Original Message----- From: Kevin Van Vechten [mailto:kevin@opendarwin.org] Sent: Friday, May 05, 2006 2:33 PM To: Philip Lukidis Cc: darwin-dev(a)lists.apple.com Subject: Re: question for CFRunLoopStop() On May 5, 2006, at 8:46 AM, Philip Lukidis wrote: > Hello. I hope that I'm posting this to the correct list. Yep. > Concerning CF, I was wondering if the following scenario is correct: > A "parent" thread creates a child thread via the pthread library. > The child thread has only 1 runloop source on it (a timer in fact), > and once the timer is applied onto the child runloop by the child > itself, the child proceeds to call CFRunLoopRun() on itself. Now > the parent is responsible for running down this child on demand. > Can the parent rundown the child by: I'm not sure what you mean by "rundown," but I'll assume you mean stop the child's runloop. > -invalidating the timer (via CFRunLoopTimerInvalidate()) > -removing the timer (via CFRunLoopRemoveTimer()) It's my understanding that a RunLoop will stop running when it has no more valid sources or timers to listen to. So if there is only one timer in the run loop, either of these would accomplish your goal. > -calling CFRunLoopIsWaiting() in a while loop until it returns > true (which indicates that all callbacks have drained and that it > is waiting again, but of course since the timer was invalidated it > can never be called again). Of course I should NOT holding a > resource which the callback might need in order to execute and exit. While I'm sure you could make something like this work, it's pretty contrived. > -calling CFRunLoopStop() Yes, this will stop the run loop (even if it still has valid sources). > -calling pthread_join() on the pthread I don't think this will stop the run loop. Instead, it will block the parent thread until the child thread exits. > Can this also be extended to other runloop sources, by using > CFRunLoopSourceInvalidate() instead of CFRunLoopTimerInvalidate(), > and CFRunLoopRemoveSource() instead of CFRunLoopRemoveTimer()? For sources that are of type CFRunLoopSourceRef, yes. > If these procedures are incorrect, why so, and what are the > alternatives? I don't see any of the above as "alternatives." In your case, with only one runloop source, CFRunLoopTimerInvalidate(), CFRunLoopRemoveTimer(), and CFRunLoopStop() all have the same end- result. However, this is a consequence of a simple example, and not generally true. Invalidating and removing a source have different semantics. For example, you may want to invalidate a source (no matter how many runloops may be using it), or alternatively you may want to remove a source from a particular runloop but keep it as a source in another runloop (or perhaps add it back to the same runloop at a later time). Stopping a runloop doesn't affect any of the sources, so it can be restarted at a later time in the same configuration that it was in originally. - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: question for CFRunLoopStop()
by Philip Lukidis 05 May '06

05 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcZwW7Zvhl1PW7DTS1yJN6opfyysYwAEZFXA Thread-topic: question for CFRunLoopStop() I forgot to mention the symptoms to my problem. The problem followed the scenario laid out in the case of the parent thread running down the child thread, which had a timer on its runloop. Sometimes the child "timer thread" had exited by the time the parent called CFRunLoopStop() was (so the parent was scribbling in random memory, as the runloop was deallocated). But I figured out the parent was provoking the child to exit by removing the timer from the runloop, so there was an actual race condition here. Would it be better for the parent to remove the timer from the loop, or call CFRunLoopStop()? thanks, Philip Lukidis -----Original Message----- From: darwin-dev-bounces+plukidis=guillemot.com(a)lists.apple.com [mailto:darwin-dev-bounces+plukidis=guillemot.com@lists.apple.com]On Behalf Of Philip Lukidis Sent: Friday, May 05, 2006 11:47 AM To: darwin-dev(a)lists.apple.com Subject: question for CFRunLoopStop() Hello. I hope that I'm posting this to the correct list. Concerning CF, I was wondering if the following scenario is correct: A "parent" thread creates a child thread via the pthread library. The child thread has only 1 runloop source on it (a timer in fact), and once the timer is applied onto the child runloop by the child itself, the child proceeds to call CFRunLoopRun() on itself. Now the parent is responsible for running down this child on demand. Can the parent rundown the child by: -invalidating the timer (via CFRunLoopTimerInvalidate()) -removing the timer (via CFRunLoopRemoveTimer()) -calling CFRunLoopIsWaiting() in a while loop until it returns true (which indicates that all callbacks have drained and that it is waiting again, but of course since the timer was invalidated it can never be called again). Of course I should NOT holding a resource which the callback might need in order to execute and exit. -calling CFRunLoopStop() -calling pthread_join() on the pthread Can this also be extended to other runloop sources, by using CFRunLoopSourceInvalidate() instead of CFRunLoopTimerInvalidate(), and CFRunLoopRemoveSource() instead of CFRunLoopRemoveTimer()? If these procedures are incorrect, why so, and what are the alternatives? thanks, Philip Lukidis _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/plukidis%40guillemot.com This email sent to plukidis(a)guillemot.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0