November 2007 - Darwin-dev - lists.apple.com

Re: Why no crash reporter if I install some signal handler on Leopard
by Terry Lambert 28 Nov '07

28 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com The following will work, but it's not ideal: ======= #include <signal.h> #include <stdio.h> void sig_abort(int sig) { printf("Application has been abort\n"); abort(); } Very true. -- Terry _______________________________________________ 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… On Nov 27, 2007, at 4:36 PM, Jim Magee wrote: On Nov 27, 2007, at 5:42 PM, Terry Lambert wrote: ... It's not ideal because you can't really rethrow the abort with the same stack, you will always show as being in the trap handler (the stack for a crash report looks something like this (on a PPC): It's also not ideal because printf() is not signal-handler-safe. ;-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Why no crash reporter if I install some signal handler on Leopard
by Jim Magee 28 Nov '07

28 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com The following will work, but it's not ideal: ======= #include <signal.h> #include <stdio.h> void sig_abort(int sig) { printf("Application has been abort\n"); abort(); } It's also not ideal because printf() is not signal-handler-safe. ;-) --Jim _______________________________________________ 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… On Nov 27, 2007, at 5:42 PM, Terry Lambert wrote: ... It's not ideal because you can't really rethrow the abort with the same stack, you will always show as being in the trap handler (the stack for a crash report looks something like this (on a PPC): This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resident Memory, Private Memory, Shared Memory (top, Activity Monitor and vmmap)
by Jim Magee 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Virtual memory in Mac OS X is managed in a number of ways: The resident memory size: The Private and Shared memory sizes: --Jim On Nov 27, 2007, at 1:04 PM, Markus Hanauska wrote: Hi! 1. The Resident Memory Size (aka Real Memory) 2. The Private Memory Size 3. The Shared Memory Size How comes 1 + 2 != 3??? Is this really so hard to answer? Okay, your turn, please share you wisdom :) -- Best Regards, Markus Hanauska _______________________________________________ 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/jmagee%40apple.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… Mike Smith covered a lot of issues, and why it is difficult to make assumptions about this accounting. Here's some more: - physical memory pages are filled with the contents of virtual memory objects - many processes can have many (distinct or overlapping) ranges of these objects mapped into their task virtual address spaces - pmaps reflect the virtual address space to a real (processor-MMU- aware) representation of virtual memory for the task/process - shared regions of address spaces/pmaps optimize overhead for commonly used ranges of address space - but make per-process accounting difficult This value as returned by task_info() indicates how many page-level pmap mappings are currently present in the task's address space. In other words, how many valid page table entries there are for this processes current use of its virtual address space. When a process actually does a load/store from an address, a mapping is normally established for the page in question - raising this value (but nothing guarantees that the system wont add some mappings on its own - to make the overhead of future references less). Lots of things can cause mappings to be be removed once they are entered into a pmap (e.g. unmapping a range of addresses, the memory object's contents being evicted from memory under memory pressure, or copy-on-write operations for the same object in some other process may require all mappings for that object range be removed from all the pmaps currently referencing it - among others). Shared region pmaps are a part of every pmap that contains them, so there is no way to distinguish page-table entries from one process to another. So, as Mike said, this number is a "reasonable approximation" of the pages immediately in use by a process (or available for use by the process without faulting the MMU). Are calculated by walking the virtual address space of a task, looking at the objects mapped there, the resident page counts in those objects, and the reference counts on those objects to try and approximate the number of pages that fall into each category. But if the objects are bigger than what we have mapped, we may not be able to make dead accurate accounting. And, at its heart, all of this is based on the "associated with no process in particular" collection of objects and their resident page counts. We then try and approximate all this info back through the virtual address space mappings to a particular task. Private and shared memory sizes are an even greater approximation than the resident memory size. But they return different info. The private and shared memory counts say "how many pages of the objects I have mapped are cached in memory", regardless of whether I've accessed them yet/lately, where the resident memory size says "how many page- table-entries does my process already have to quickly access those cached pages". So, it is almost never going to be the case that they add up to each other - even in the simple cases with no sharing and mapping in entire objects. But both are useful to know and why we report both. I'd like to ask a simple question. This question has been asked about ten times on various mailing lists here in the past and whenever somebody asked this question directly or indirectly, he never received a reply. Either the question was ignored in the reply or the post never received any reply in the first place. This either means nobody wants to answer it or nobody can answer it... maybe nobody knows it, which would be very, very sad, as that is one of the most fundamental things one should know. It's also nowhere documented. I even searched many MacOS internals books for an answer, but I had no success. It's simply not explained anywhere. It can't be that we have to file a support incident just to receive a reply to this very simple question. So I try it again and I will try it over and over again, till I find someone who can answer it. When you use top or Activity Monitor, does not matter, you receive three interesting memory results per process. The VM stats are not interesting (no matter if VM private or VM total). The three values of interest are: So far, all these values seems self explaining... but they are not at all for one single reason: There are processes, where 1 + 2 is much bigger than 3. How comes? Where is the memory lost? Which pages count towards 1 or 2, but are ignored for 3? For other processes, 1 + 2 is much smaller than 3. How comes? Which memory is ignored for 3, but is accounted towards 1 or 2? I looked at the source of top, here's what I found out (some people might find this useful): A) The resident memory is obtained using the call task_info(). Since it is nowhere documented what this call will count towards memory of the task and what not in the field resident_size, it's basically magic and I can't investigate this value any further. B) The other two values are obtained by getting every memory region of a process using mach_vm_region() (same function vmmap uses) and show some interesting behavior. Basically all private memory is summed up as private memory. Real shared memory (e.g. mmap memory) is summed up as shared memory. This is expected behavior. Memory that is in theory share-able (Copy on write) is treated differently depending on whether it is actually shared. E.g. code of the process or libraries used by the process is counted towards private memory if it is only referenced once (it could be shared, but currently it isn't). That means libraries shared with other processes are counted towards shared memory. This is indeed very clever. If I start a second instance of my process, my code regions are shared between both processes, so the private memory decreases and the shared one raises, which reflects what really goes on within the system. Same with some library code. E.g. libraries that only my process uses are first counted towards my private memory. With a second instance using them, they are counted towards shared memory. You see, pretty clever and desired behavior. C) Only "touched" memory is accounted at all. This is also very clever. Just because I load a library does not mean, that all library code is in memory. Only space for all is reserved. Unless I ever access any page of that library, the page is not really in memory. Same for my code or malloc'ed memory. This is also desired behavior. D) Still top overestimates the real memory my process uses. E.g. I use a library that another process uses, too. I only need one function of the library. If I was the only one using it, only the page containing this function would be real memory, that means only one page would be accounted towards my process (the rest stayed virtual). Now the other process uses all of the library. Because of this, all pages of the library are loaded to real memory. Since I use the library, too, now all the loaded pages are accounted to my process as shared memory, just as they are accounted to the other process. In fact, only one of the pages is in memory because of my process and in use by my process. The rest is only in memory because of the other process. So more shared memory is accounted towards my process than my process actually uses. But since it is accounted towards shared memory, this is something I can live with (forcing the kernel to remember because of which process which virtual page has been mapped into physical memory would be pretty much overkill and bloat all memory structures enormously). After reading the top source, I understand pretty much how the values Shared and Private memory are calculated (the source basically is self explaining in this aspect), what they actually mean and how to interpret them. But I have no idea what resident memory is, what it means, where it comes from and why it is so much different than the sum of private and shared for many processes. Also playing around with vmmap could not really answer that. BTW, vmmap is pretty much useless to build a tool to determine the real memory use of a process. This is because a section, that is COW (Copy on Write) will stay COW, even if some pages within it have already been copied. These pages would now count towards private, but vmmap won't tell me how many pages have already been shadowed like this and whether a page is shared between many processes or already private towards one of the processes makes a huge different. What I'm missing is a tool that works just like vmmap, but reports statistics about every single *PAGE* of memory of a process space, not just every larger region and that takes into account if this page has been copied or not for a COW page. Then one could really make a tool that prints out the real shared and private memory amounts of my process, except for issue (D), where everything of the library that has physical memory is counted towards my shared memory (to correct that, I had to eliminate all other processes using the library and then create the values). This email sent to jmagee(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Why no crash reporter if I install some signal handler on Leopard
by Terry Lambert 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com The OP understands that. The following will work, but it's not ideal: ======= #include <signal.h> #include <stdio.h> void sig_abort(int sig) { printf("Application has been abort\n"); abort(); } int main(int argc, char* argv[]) { struct sigaction sa; sa.sa_handler = sig_abort; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESETHAND; if (sigaction(SIGABRT, &sa, NULL) == -1) { perror("sigaction"); exit(0); } while (1) {} return 0; } ======= Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x916fd1f8 __kill + 12 1 libSystem.B.dylib 0x9179e820 abort + 84 2 foo 0x00001e8c sig_abort + 44 3 libSystem.B.dylib 0x916fb100 _sigtramp + 64 -- Terry _______________________________________________ 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… On Nov 27, 2007, at 9:28 AM, Steve Sisak wrote: At 1:19 PM -0800 11/26/07, Terry Lambert wrote: A consequence of this is that caught signals that would otherwise be fatal no longer trigger crash reports. He asks what to do if he wants to do something in response to the signal (and therefore needs to install an handler), but still wants a crash report generated: On Nov 26, 2007, at 1:23 AM, zhanglin <zhanglin.zhou(a)gmail.com> wrote: If I want to install the signal handler and make the crash reporter dialog to be shown too, what should I do? Pass the exception in signal hander? How? Is there a best practice for generating a crash report for a signal that one partially handles? Off the top of my head, I'm not sure. CrashReporter tends to be launched by launchd when something causes abnormal_exit_notify() to be called in the kernel, thus raising the exception EXC_CRASH. THis is handled in osfmk/kern/exception.c. This is normally called in proc_prepareexit() from either exit1() (via the exit() system call) or from proc_exit(), but doesn't happen if the system is in the process of being shutdown, or the signal is not indicated to normally result in a core file. proc_exit() in turn is called when your process is exiting, and the last thread exits uninterruptible state and would otherwise run up and return to user space, but instead ends up calling thread_terminate_self() because it's been killed/terminated/aborted/whatever. It's not ideal because you can't really rethrow the abort with the same stack, you will always show as being in the trap handler (the stack for a crash report looks something like this (on a PPC): Thread 0 crashed with PPC Thread State 32: srr0: 0x916fd1f8 srr1: 0x0000d030 dar: 0xa0265520 dsisr: 0x0a000000 r0: 0x00000025 r1: 0x00026900 r2: 0x00000008 r3: 0x00000000 r4: 0x00000000 r5: 0x00000001 r6: 0x0000000a r7: 0x0000001b r8: 0x00000889 r9: 0x00000889 r10: 0x916c5d7c r11: 0xa0267448 r12: 0x916fd1e4 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffff8e4 r27: 0x00026a88 r28: 0x00026a68 r29: 0x00000014 r30: 0x00026960 r31: 0x9179e7d8 cr: 0x22000002 xer: 0x00000000 lr: 0x9179e824 ctr: 0x916fd1e4 vrsave: 0x00000000 It might be cleaner to dump the mcontext information himself, which will be hard, since we intentionally make these values opaque to avoid people other than debugger writers, CrashReporter, etc. messing with them and tying us to an ABI that we might need to change to add features or resolve issues at some point. The people who write those types of tools understand that they may be broken by system updates. On the other hand, if he is handling the stack traceback on his own, he should be OK. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resident Memory, Private Memory, Shared Memory (top, Activity Monitor and vmmap)
by Michael Smith 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 27, 2007, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: It is not a question with a simple answer. This question has been asked about ten times on various mailing lists here in the past and whenever somebody asked this question directly or indirectly, he never received a reply. Either the question was ignored in the reply or the post never received any reply in the first place. This either means nobody wants to answer it or nobody can answer it... maybe nobody knows it, which would be very, very sad, as that is one of the most fundamental things one should know. You are assuming that there is a simple answer, which there is not. Now you're just being silly. When you use top or Activity Monitor, does not matter, you receive three interesting memory results per process. The VM stats are not interesting (no matter if VM private or VM total). The three values of interest are: 1. The Resident Memory Size (aka Real Memory) 2. The Private Memory Size 3. The Shared Memory Size So far, all these values seems self explaining... but they are not at all for one single reason: Because they aren't related in that fashion. What makes you think it is lost? I looked at the source of top, here's what I found out (some people might find this useful): A) The resident memory is obtained using the call task_info(). Since it is nowhere documented what this call will count towards memory of the task and what not in the field resident_size, it's basically magic and I can't investigate this value any further. B) The other two values are obtained by getting every memory region of a process using mach_vm_region() (same function vmmap uses) and show some interesting behavior. Basically all private memory is summed up as private memory. Real shared memory (e.g. mmap memory) is summed up as shared memory. This is expected behavior. Memory that is in theory share-able (Copy on write) is treated differently depending on whether it is actually shared. E.g. code of the process or libraries used by the process is counted towards private memory if it is only referenced once (it could be shared, but currently it isn't). That means libraries shared with other processes are counted towards shared memory. This is indeed very clever. If I start a second instance of my process, my code regions are shared between both processes, so the private memory decreases and the shared one raises, which reflects what really goes on within the system. Same with some library code. E.g. libraries that only my process uses are first counted towards my private memory. With a second instance using them, they are counted towards shared memory. You see, pretty clever and desired behavior. C) Only "touched" memory is accounted at all. This is also very clever. Just because I load a library does not mean, that all library code is in memory. Only space for all is reserved. Unless I ever access any page of that library, the page is not really in memory. Same for my code or malloc'ed memory. This is also desired behavior. Ok, so now we come to a much more interesting mistake you're making. This can be a very different number. E.g. I use a library that another process uses, too. I only need one function of the library. If I was the only one using it, only the page containing this function would be real memory, that means only one page would be accounted towards my process (the rest stayed virtual). Now the other process uses all of the library. Because of this, all pages of the library are loaded to real memory. Since I use the library, too, now all the loaded pages are accounted to my process as shared memory, just as they are accounted to the other process. In fact, only one of the pages is in memory because of my process and in use by my process. The rest is only in memory because of the other process. So more shared memory is accounted towards my process than my process actually uses. But since it is accounted towards shared memory, this is something I can live with (forcing the kernel to remember because of which process which virtual page has been mapped into physical memory would be pretty much overkill and bloat all memory structures enormously). What I'm missing is a tool that works just like vmmap, but reports statistics about every single *PAGE* of memory of a process space, not just every larger region and that takes into account if this page has been copied or not for a COW page. = Mike _______________________________________________ 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'd like to ask a simple question. This is not true; I have myself authored at least a dozen replies to variations on this basic question in multiple forums. It's also nowhere documented. This is, techically speaking, not true; it is documented by the (freely available) source code and the activity of your system. I even searched many MacOS internals books for an answer, but I had no success. It's simply not explained anywhere. It can't be that we have to file a support incident just to receive a reply to this very simple question. So I try it again and I will try it over and over again, till I find someone who can answer it. How comes 1 + 2 != 3??? What makes you think that they would be? The numbers are in no wise directly related. Perhaps the numbers aren't "self explaining" in the sense that you think they are? There are processes, where 1 + 2 is much bigger than 3. How comes? Where is the memory lost? Which pages count towards 1 or 2, but are ignored for 3? So now you admit that you don't actually know what those three numbers mean. 8) Allow me to shed, again, a little light. First - it is important to understand that Darwin has many, many categorisations for memory, and the numbers that are thrown into these three categories are in some cases approximations. Understanding the way memory is used by the system is a full-time occupation. 1. Resident Memory size: this counts (to a first approximation) physical pages that are currently mapped into the task address space. 2. Private Memory size: this counts (to a first approximation) pages that are private to the task (not shared with other tasks) 3. Shared Memory size: this counts (to a very coarse approximation due to several factors) pages that are shared with one or more other tasks in the system. 1 counts physical pages. I am assuming that with 2 and 3 you are referring to the RSHRD and RPRVT fields, which are resident shared and resident private pages. You might more reasonably assume that 1 = 2 + 3, but you'd still be bitten by the fact that things are not counted in quite the way you expect. Is this really so hard to answer? Yes, because the above (and those three numbers) are crude approximations. You might try introspecting a task's address space with vmmap and back-tracking some of the objects to see how complex things get. "resident memory" is an old OS term, and you will find it defined in many OS textbooks. If you have reached this point, it's more or less assumed that you will have read Tanenbaum or something more recent, and the concept should be self-explanatory. Actually, this is an approximation; I think you'll find that memory mapped MAP_ANON is accounted as private, MAP_PRIVATE is handled as COW and MAP_SHARED is erroneously always accounted as shared even if nobody else has that range of the object mapped. It's been some years since I looked at the code, so YMMV. It's kind of you to call shared libraries "clever", but see above inre: OS textbooks. They've been around a long time. 8) You are completely missing the shared segment, and the interesting and evil things that relate to it here. This is again an approximation. In the case of shared submaps or shared pmap regions, pages may be resident for a task that has never referenced them. Clustered pageins can also cause this behaviour. D) Still top overestimates the real memory my process uses. Top is not telling you, except in the crudest sense, how much real memory your process uses. It gives you some ballpark numbers that are indicative of the memory currently resident and mapped into your task. Understanding the real memory usage of your task is better handled with different tools. VM accounting is a very expensive way to do what you seem to be wanting to do; I would encourage you to tinker with Shark and the X-ray instruments to see if you can't get a better understanding of what your process is doing and what that costs. There would be several pages most likely referenced due to the way linkage works. It's also likely that if the framework you referenced was a system framework that it would already be mapped (due to being in the shared segment) and quite probably referenced. However, if this was the first time you had touched the library, the library might want to run its static initialisers, which would make other code pages resident and possibly create private data pages containing the results of this initialisation (or it might COW parts of the libraries data segment). It would be impossible to reasonably account for this activity without abandoning shared text/data altogether. It's called gdb. Attach it to the kernel, and start walking your task's address space. 8) I do think, however, that you are starting down a very difficult and ultimately unrewarding path. Some of the information you want is simply not available, and other pieces are obscured because of the disconnect between what your application does and how the system actually handles that activity. This email sent to site_archiver(a)lists.apple.com

1 0

Re: A change with the -n option for cp in Mac OS X 10.5
by Eric Hall 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Mail-followup-to: Darwin-dev(a)lists.apple.com On Tue, Nov 06, 2007 at 09:19:49AM -0500, Eric Gorr wrote: > Kevin Van Vechten wrote: > > Eric Gorr wrote: [snip] > > > I was just wondering if: > > > > > > > > > 1. 10.4.10 had a bug > > > 2. 10.5 has a bug > > > 3. the definition of how the -n option is supposed to work > has changed > > > > > > > > > It seems strange that cp would return an exit status of 1 now if > > > the file already exists. After all, the command will do exactly > what > > > it is supposed to do and not copy the file. > > > > > > I suppose it was #3. It looks like the exit status was changed due to > > feedback that returning a zero exit status gives no way to determine > > whether or not a file was actually copied (<rdar://problem/3624563>). > > This is a divergence from the FreeBSD behavior in 10.4.10 (FreeBSD > > introduced the non-standard -n flag). Because -n is non-standard[1], > > I'd recommend against using it. > > Ok, thanks. > > Still seems strange that it would be considered an error if the > command does what it is told to do. > [snip] I like the idea of 'cp -n' returning a non-zero status if it sees an existing file. There are times when you don't want to overwrite an existing file, but want to know if it was there *during* the cp - in particular if you're going from a case-sensitive FS to a case-insensitive FS. While 'cp -i' works fine if humans are driving, it tends to not work as well if you're doing something automated/scripted. Whether 'cp -n' should return 0 or non-zero depends on how you think about what you're asking cp to do. Are you asking it to not perform the copy for existing files, or to let you know there are existing files and not overwrite them? That said, the advice to not use it as its non-standard is probably the best course. -eric _______________________________________________ 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: Lowering Thread Priority
by Duane Murphy 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Tue, 27 Nov 2007 10:37:56 -0800, Garth Cummings wrote: >On Nov 26, 2007, at 10:17 PM, Duane Murphy wrote: > >> I would like to lower the priority of a background thread in my kext. > >You probably don't really want to do that literally. What's the >problem you're trying to solve? I have a background thread that is in contention with System IO requests to the kext. While the background thread is working system IO requests and chunks of the background work are serialized to prevent errors from occurring. If there is contention between posting an IO request to the queue versus posting a process chunk request, then I want the IO request to win. Further testing is showing that this is probably not the real problem with my performance. However, I am still interested to know what can be done if this indeed was a problem. ...Duane _______________________________________________ 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: Resident Memory, Private Memory, Shared Memory (top, Activity Monitor and vmmap)
by Alexander von Below 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Am 27.11.2007 um 19:04 schrieb Markus Hanauska: Hi! Thank you very much for this post, and for sharing your insight! Alex _______________________________________________ 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'd like to ask a simple question. This question has been asked about ten times on various mailing lists here in the past and whenever somebody asked this question directly or indirectly, he never received a reply. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Lowering Thread Priority
by Garth Cummings 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Duane, On Nov 26, 2007, at 10:17 PM, Duane Murphy wrote: --gc ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ 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 would like to lower the priority of a background thread in my kext. You probably don't really want to do that literally. What's the problem you're trying to solve? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is launchd a RAM addict?
by Dave Zarzycki 27 Nov '07

27 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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