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

Re: Correct API to implement a timer in a real-time thread
by Christian Brunschen 05 Jan '06

05 Jan '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On Thu, 5 Jan 2006, Stéphane Letz wrote: But that's easy - here's some pseudocode: time_t start = now(); time_t next = start; time_t interval = // ... while(true) { time_t now = now(); while (next < now) { next += interval; } sleep(next - now); // do something } time_t start = now(); time_t next = start; time_t interval = // ... while(true) { time_t now = now(); next += interval; time_t ahead = next - now; if (ahead > 0) { sleep(ahead); } // do something } [ ... ] Best wishes, // Christian _______________________________________________ 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 [ ... ] The thing is that when using this kind of functions, i have to deal with cases where an abnormal latency occur in the system, then the wait function returns too late, I have to compensate for that for the next interrupt and so on. This will attempt to 'do something' at fixed intervals. Even if there is latency or an unexpected delay at some point, the next time to wake up will still be "start + (n * interval)" for soem value of n. If the unexpected latency exceeds one interval, then an interval will be skipped. If you need to avoid skipping any invocations - in other words, if such a latency burst should not result in any invocations being skipped, but instead in perhaps severl invocations happening as quickly as possible until the system has caught up - then you can modify the pseudocode above: This will never skip any invocations; but if your system is loaded, or if your 'do something' processing takes too long, this will end up being permanently behind its expetcted timer, and start hogging CPU. Stephane

1 0

Re: Correct API to implement a timer in a real-time thread
by Stéphane Letz 05 Jan '06

05 Jan '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Le 5 janv. 06 à 13:54, philippe wicker a écrit : On Jan 5, 2006, at 12:25 PM, Stéphane Letz wrote: Hi, pthread_mutex_lock(mutex); int status; while (1) { status = pthread_cond_timedwait(cond, mutex, absolute_time); if (status == EINVAL) break; // ERROR: some invalid parameters if (status == ETIMEDOUT) break; // OK, the actual time-out } pthread_mutex_unlock(mutex); // Check the status and do the timer thread job Thanks Stephane Letz Hi Philippe, Stephane _______________________________________________ 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… We need to setup a 1 millisecond periodic timer used in a real- time (time constraint) thread in a pure C console program. We first tried to use the carbon Timer manager API (with NewTimerUPP and a timeManagerTask ...) but without being able to access the thread that call the timer task in order to setup its scheduling property to be "time constraint". We try also low-level function like mach_wait_until but had problems on Panther. What is the recommended way (API...) to implement a timer? Dunno if this is the recommended API but I would do it using the POSIX API pthread_cond_timedwait (or alternatively pthread_cond_timedwait_relative_np). Create your timer thread with pthread_create, and call mach specific API to set the "time constraint" scheduling policy. You could also use CoreAudio SDK utilities CAPThread, CAMutex and CAGuard which are nice C++ encapsulations of POSIX thread, mutex and variable condition concepts that allow you to do the same things in a simpler way. "pthread_cond_timedwait" requires a mutex and a condvar. In your case you'll use only the "time out" part of the API but you still need to pass valid mutex and cond although the mutex will never be signaled. Just in case, be aware that "pthread_cond_timedwait" can spuriously return with a "no error (0)" status. To manage this situation enclose the "pthread_cond_timedwait" call within a loop such as: It may not be necessary in your case to lock the mutex but I don't know if the OS will correctly deal with that. It expects a locked mutex at entry, unlocks it to put the caller thread to sleep and relocks it when the thread has to wake up. Thanks for the info, actually I was wondering if a higher-level API was available because I would prefer not having to use function that "wait until a specified date". The thing is that when using this kind of functions, i have to deal with cases where an abnormal latency occur in the system, then the wait function returns too late, I have to compensate for that for the next interrupt and so on. If I use a CoreAudio task as a way to schedule my 1 millisecond interrupt, the nice thing is that CoreAudio seems to automically ajust/compensate timing deviations. I can have a serie of call that on average is 1000us. I would like to have timer API that allows to setup the same thing. This email sent to site_archiver(a)lists.apple.com

1 0

Correct API to implement a timer in a real-time thread
by Stéphane Letz 05 Jan '06

05 Jan '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Hi, What is the recommended way (API...) to implement a timer? Thanks Stephane Letz _______________________________________________ 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… We need to setup a 1 millisecond periodic timer used in a real-time (time constraint) thread in a pure C console program. We first tried to use the carbon Timer manager API (with NewTimerUPP and a timeManagerTask ...) but without being able to access the thread that call the timer task in order to setup its scheduling property to be "time constraint". We try also low-level function like mach_wait_until but had problems on Panther. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit
by Martin Costabel 04 Jan '06

04 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5 (Macintosh/20051201) Martin Costabel wrote: [] __Unwind_GetIP __Unwind_GetLanguageSpecificData __Unwind_GetRegionStart These come from the module eh_personality.o from libstdc++.a. -- Martin _______________________________________________ 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… time and DYLD_PRINT_LIBRARIES and DYLD_PRINT_BINDINGS at run time. What I observed makes me believe that the crucial variable is __Unwind_RaiseException To be complete for the record: There are a couple of other symbols behaving in the same way: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit
by Martin Costabel 04 Jan '06

04 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5 (Macintosh/20051201) Hi Ananda, Ananda Tallur wrote: [] Glad it worked. I still have few questions : __Unwind_RaiseException % nm -o libThrow.dylib | grep "__.*RaiseException" libThrow.dylib:eh_throw.o: u __Unwind_RaiseException libThrow.dylib:unwind-dw2.o: 000091c8 t __Unwind_RaiseException libThrow.dylib:unwind-dw2.o: 00009108 t __Unwind_RaiseException_Phase2 According to "man nm", the lower case "u" means: A lower case u in a dynamic shared library indicates a unde- fined reference to a private external in another module in the same library. g++-3.3 -o test main.o -lgcc_s.1 -L. -lThrow -- Martin _______________________________________________ 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… I have tried adding -single_module to dynamic library link options : g++ -dynamiclib -flat_namespace -single_module -o libThrow.dylib throw.o -lIOKit And it works in the sample program ! Thank you for your help. I still have to test this options in my complete application, but I am confident it will solve the problem. -> do you know how it solves the exceptions problem, when linking with IOKit, itself linked to libgcc_s.1.dylib ? I would not go as far as claiming that I *know* anything about these things :-) I looked at your example with flags like -whyload at linking time and DYLD_PRINT_LIBRARIES and DYLD_PRINT_BINDINGS at run time. What I observed makes me believe that the crucial variable is If you compile your libThrow.dylib without the -single_module flag (with g++-3.3), then this symbol is undefined in one module and defined as private extern in another module: Why these "modules" are there, and why this symbol is there as "u", I have no idea, but this is the reason that ultimately leads to the crash: Unfortunately, the dynamic linker dyld in MacOSX 10.4 is now so fast that it doesn't have the time to read "man nm", so it links this symbol to whatever other library offers it and happens to be loaded at runtime, in this case libgcc_s.1.dylib which is loaded because of -lIOKit. The evidence is here: % env DYLD_PRINT_BINDINGS=1 ./test | & grep "__.*RaiseException" dyld: bind: libThrow.dylib:__Unwind_RaiseException$lazy_ptr = libgcc_s.1.dylib:__Unwind_RaiseException, *0x00259c9c = 0x913b224c The crash comes because at runtime, there are now two conflicting definitions of that variable, the one from libgcc_s.1.dylib and the private extern from libThrow.dylib. If you use -single-module, then the undefined symbol is resolved at link time, and there is no more reason to link to anything in libgcc_s.1.dylib at runtime. The opposite solution is also possible: If you don't use -single_mdoule for the library, but build your executable by linking explicitly to libgcc_s.1.dylib: then that symbol will remain undefined in ./test, and it will be resolved at runtime from libgcc_s.1.dylib both in ./test and in libThrow.dylib, so there is only one definition of this symbol, and no crash occurs (well, there is still the second definition as a private extern in libThrow.dylib, but this doesn't seem to hurt). I would say the bug is mainly to blame on dyld which is known in other cses, too, for being sloppy with choosing which library to use for resolving symbols. -> Is there a web page explaining in details (more than man ldd) the different link options : -flat_namespace, -single_module, etc.. I don't know. There is man ld, man dyld, man nm, info gcc, and if you have it installed, file:///Developer/ADC\ Reference\ Library/documentation/DeveloperTools/ , but there is not much more information there than in the man pages. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOHIDFamily
by Kevin Van Vechten 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Dec 30, 2005, at 12:14 PM, Steve Checkoway wrote: On Dec 30, 2005, at 10:17 AM, ebold(a)apple.com wrote: You can also use darwinbuild itself to copy in missing files: $ darwinbuild -load PowerManagement $ darwinbuild -load -headers PowerManagement - 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… That's a private header installed from the PowerManagement project. You can easily install the header by hand into IOKit.framework/Headers/ ps. Technically it should be in IOKit.framework/PrivateHeaders/ps, but I think either will work. Thanks, that worked perfectly. Will load the pre-built PowerManagement root (or a locally-built PowerManagement root if you have one) into the BuildRoot. You can also install only the results of the installhdrs phase using the following: I have no idea whether it should have been installed by darwinbuild. Nor I, but that's probably a discussion for another list. Yes, darwinbuild should have installed this for you, I'll have to look into why this dependency wasn't automatically detected. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit
by Ananda Tallur 03 Jan '06

03 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Martin, Thank you very much for your answer, I still have few questions : Anand On 2 janv. 06, at 23:20, Martin Costabel wrote: Ananda Tallur wrote: [] Try if building your library with the -single_module flag helps. -- Martin _______________________________________________ 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… I have tried adding -single_module to dynamic library link options : g++ -dynamiclib -flat_namespace -single_module -o libThrow.dylib throw.o -lIOKit And it works in the sample program ! Thank you for your help. I still have to test this options in my complete application, but I am confident it will solve the problem. -> do you know how it solves the exceptions problem, when linking with IOKit, itself linked to libgcc_s.1.dylib ? -> Is there a web page explaining in details (more than man ldd) the different link options : -flat_namespace, -single_module, etc.. g++ -dynamiclib -flat_namespace -o libThrow.dylib throw.o - lIOKit This email sent to site_archiver(a)lists.apple.com

1 0

Re: Exception catching problem since 10.4.3 using gcc 3.3 - IOKit
by Martin Costabel 02 Jan '06

02 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5 (Macintosh/20051201) Ananda Tallur wrote: [] Try if building your library with the -single_module flag helps. -- Martin _______________________________________________ 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… g++ -dynamiclib -flat_namespace -o libThrow.dylib throw.o -lIOKit This email sent to site_archiver(a)lists.apple.com

1 0

Exception catching problem since 10.4.3 using gcc 3.3 - IOKit
by Ananda Tallur 02 Jan '06

02 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Anand Context : -------- This problems occurs when : -> Compiling a C++ program with gcc3.3 -> Linking using flat namespace -> Linking this program againt IOKit Description : -------- Diagnosis : ------- Sample program : ------- ------ file throw.cpp (dynamic lib throwing an exception): -- #include <iostream.h> class Exc1 { public: Exc1 () {} ~Exc1 () {} }; void dothrow () { std::cout << "before throw" << std::endl; throw Exc1 (); } -- file main.cpp : -- #include <stdio.h> #include <iostream.h> void dothrow (); class Exc1 { public: Exc1 (); ~Exc1 (); }; _______________________________________________ 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… We have found a problem in Mac OS X 10.4.3, which was not present in 10.4.2, concerning exception catching (see details below). This problem's cause is IOKit, which is dynamically linked to libgcc_s.1.dylib since 10.4.3, certainly by mistake. The problem is summed up below, with a small example program which demonstrate the problem . A bug report has already been sent by us to Apple a few day ago (Problem ID: 4393607). Does anybody already has come accross this problem, and know how to work around it ? Thank you for your answers, Wishing a happy new year to darwin-dev list readers. The problem occurs for programs made up of : a main binary, and at least a dynamic library compiled using flat namespace. The problem only occurs for programs which are linked against IOKit. Exceptions which are thrown from a dynamic library function cannot be catched in the main program. An abort is generated instead. This problem has apparead in Mac OS X 10.4.3, and was not present in 10.4.2. With command otool -L, We have noticed that IOKit is now dynamically linked against libgcc_s.1.dylib. This was not the case in Mac OS X 10.4.2 and former versions. Interestingly, libggcc_s.1.dylib is a component of gcc 4 runtime, and we are using gcc 3.3. When using gcc 3.3 on Mac OS X, the runtime used is a static version, and not the dylib version. Therefore, the problem could come from this mix of gcc 3.3 / gcc 4 runtimes. There may be some interference between the two, preventing exceptions to be correctly handled in some cases. Output of otool command on MacOS X 10.4.3 : command : otool -L /System/Library/Frameworks/IOKit.framework/ Versions/Current/IOKit result : /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/ SystemConfiguration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 368.18.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) The example contains three files which are reproduced below. - throw.cpp : a dynamic library with only one function : dothrow - main.cpp : main program, which calls dothrow and tries to catch the exception - Makefile : the Makefile To compile the example type the : make The program test is generated Launch the program : ./test If the problem is present (with Mac OX 10.4.3), the output is the following : -- trying lib->main exception before throw zsh: abort ./test -- If the problem is not present : with Mac OS 10.4.2, or removing - flat_namespace options from the Makefile, the output is the following : -- trying lib->main exception before throw ok catched in main -- We would like to know : - if other people have come accross the same problem- - if there is a workaround knowing that we have to use flat_namespace option, due to other constraints in our project. - if this problem in IOKit is planned to be fixed in next Mac OS version : 10.4.4 int main (void) { try { std::cout << "trying lib->main exception" << std::endl; dothrow (); } catch (...) { std::cout << "ok catched in main" << std::endl; } } -- Makefile : -- test:libThrow.dylib main.o g++ -o test main.o -lthrow -L./ throw.o:throw.cpp g++ -c -o throw.o throw.cpp main.o:main.cpp g++ -c -o main.o main.cpp libThrow.dylib:throw.o g++ -dynamiclib -flat_namespace -o libThrow.dylib throw.o - lIOKit -- This email sent to site_archiver(a)lists.apple.com

1 0