April 2010 - Darwin-dev - lists.apple.com

Re: Crash with FD_SET when there are more than 1024 open files
by Stuart Smith 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acrc6tSNp4VmDxpv00SS+Z+szqJgow== Thread-topic: Crash with FD_SET when there are more than 1024 open files User-agent: Microsoft-Entourage/12.23.0.091001 on 4/15/10 12:04 PM, darwin-dev-request(a)lists.apple.com at darwin-dev-request(a)lists.apple.com wrote: > Message: 2 > Date: Thu, 15 Apr 2010 17:54:03 +0200 > From: lists(a)haller-berlin.de (Stefan Haller) > Subject: Crash with FD_SET when there are more than 1024 open files > To: darwin-dev(a)lists.apple.com > Message-ID: <1jh00i6.c1efku18ojrlsM%lists(a)haller-berlin.de> > > We are investigating a reproducible crash that happens in Bonjour code > when we have many files open. The crash happens in > DNSServiceProcessResult (part of mDNSResponder), which contains the > following code: > > static int more_bytes(dnssd_sock_t sd) > { > struct timeval tv = { 0, 0 }; > fd_set readfds; > FD_ZERO(&readfds); > FD_SET(sd, &readfds); > return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); > } > > If sd is greater than 1024, bad things happen; in particular, if sd > happens to be 1669, you get an immediate crash on return from the > function because the code overwrites the saved ebp register. > > See also <rdar://problem/7701369> to which I attached a small example > program that demonstrates the crash. > > Now, this makes me wonder whether it is ever possible, for any > application, to exceed the number of 1024 open files. Even if Apple > fixes that particular piece of code (for example by defining FD_SETSIZE > to a greater value before including <sys/types.h>), other code which we > can't control could have the same problem. That could be OS code, > third-party libraries that we link against, plugins that we load. > > One possible workaround would be to somehow ensure that there's always a > free range of file descriptors below 1024 available for code other than > ours. I wouldn't know how to do that though; any suggestions? > > (We made a quick test to open a hundred dummy files before opening our > real files, and close them right before calling the offending OS > function, in the hope that that the Bonjour code would then use these; > this didn't help though.) > > Thanks, > Stefan > > > -- > Stefan Haller > Berlin, Germany > http://www.haller-berlin.de/ It seems you have a few alternatives: recompile with a larger value for FD_SETSIZE check that sd+1 is <= FD_SETSIZE before calling select(), although that isn't particularly helpful.... use poll() instead of select() Interestingly, under 10.6, the man page for select() says: Compatibility select() now returns with errno set to EINVAL when nfds is greater than FD_SETSIZE. Use a smaller value for nfds or compile with -D_DARWIN_UNLIMITED_SELECT. So I have to ask - what version of Mac OS X are you on? We ran into this problem a while ago, our solution was to avoid select(). Stuart _______________________________________________ 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: Crash with FD_SET when there are more than 1024 open files
by Terry Lambert 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com We are investigating a reproducible crash that happens in Bonjour code when we have many files open. The crash happens in DNSServiceProcessResult (part of mDNSResponder), which contains the following code: /*do this before #include <sys/select.h> */ #define _DARWIN_UNLIMITED_SELECT ... FD_ZERO(readfdsp); FD_SET(sd, readfdsp); return(select(sd+1, readfdsp, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); } -- 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 Apr 15, 2010, at 8:54 AM, Stefan Haller wrote: static int more_bytes(dnssd_sock_t sd) { struct timeval tv = { 0, 0 }; fd_set readfds; FD_ZERO(&readfds); FD_SET(sd, &readfds); return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); } Are you recompiling this code yourself? If so, here's the trivial fix for this: static int more_bytes(dnssd_sock_t sd) { struct timeval tv = { 0, 0 }; int my_fdset[1 + sd / (8 * sizeof(int))]; /* c99 magic auto size arrays */ fd_set *readfdsp = (void *)&my_fdset[0]; /* convert array to pointer to struct containing bit vector */ The select nfds parameter is limited in the procedural implementation of select() itself, but that limit is a problem with the POSIX assumptions about internal implementation details of the system call limiting the copyin size to a stack declared fd_set internally, rather than an allocated data area. It's more or less a bogus limitation on select by POSIX, and is only enforced in user space in Libc. Obviously, the FD_* macros don't enforce this limitation -- and would have a hard time doing so, without potentially reevaluating their arguments, which may have side effects, and which is prohibited (also by POSIX; there's a specific negative assertion test in the validation suite), so there's no way to keep you from shooting yourself in the foot. All that said, there is no existing Apple software which uses the DNSServiceProcessResult() function, so it's likely that you could do whatever you are doing which requires using that function a bit differently, and avoid the problem entirely while at the same time getting better structured code out of the deal. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Crash with FD_SET when there are more than 1024 open files
by Gabriel Beauchemin 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=0Ai4c87XT6GOH6GDHVNrv/m3nGLGzQYCeIRuLu9rzKc=; b=dvmNDBizfdGuNa0I7awq4XVlZsT35Bwh3jDIViWy0Sni58j4HEv/3okbfePUSISBH7 ajFGDar+qKUCnwAJRy3dhach+Dn9m1RENVGXLsHBARnlWRwuG5izx4hM8ttznwZGQVCr TCWwBguVu9tSpAMAESOUH6Bkl4t7WePLTTWqQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Jjdlcau57+IfNefcyaE4d9yLN1E6evt3jHu0tE7dnfsEc4/94F9ly8uDstTIpdJzyl 08WXXLYxVK04r73pdxd1HDfxu03hql7OINTlnefVlnRJZ2azx1ElYKhQ+QjcgSRlpoWa n6yVv51XfzwRC7Nne6bgSloUEktRj3GDBa2Tg= This is a very well know issue. Work-arounds include using epoll(linux) or kqueue(bsd). select() doesn't scale very well when handling a large number of fd (10k+), and will certainly crash (stack corruption) when more than FD_SETSIZE fds are opened. On Thu, Apr 15, 2010 at 2:18 PM, Joel Reymont <joelr1(a)gmail.com> wrote: > I was running Erlang which I compiled myself just so that it used my modified FD_SETSIZE. > > On Apr 15, 2010, at 7:03 PM, Stefan Haller wrote: > >> Then you may just have been lucky. The Bonjour problem I discribed >> occurs whenever you open an NSOpenPanel or NSSavePanel while you are on >> a LAN with other Macs. So either this doesn't apply to you, or the code >> did overwrite random bits somewhere on your stack and you just didn't >> notice. >> > > --- > http://es.linkedin.com/in/joelreymont > > _______________________________________________ > 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/g-beauchemin%40videotron.… > > This email sent to g-beauchemin(a)videotron.ca > _______________________________________________ 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: Crash with FD_SET when there are more than 1024 open files
by Joel Reymont 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=O0kNjJA1XRE+mj4ZaZWKf6i9UuAPWlW2Pksg1/vSmbI=; b=OUuxAuALQed+pbEzgoh4g+hkErx+BVyr0y9Y7R7kHuZwzemm4xvvYaih2HpBK9y0kE 8yo/pmbnpQsUoQx/5mnhtRDekX0pE3Q5umDzHRYmIZGjNBTaghiJi9xlBGjycLJKNhf8 FpFOhwBxK338apegfXesqMPOtTTeLU8dG68Hs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=q+m8r4vWlRpiZeqdmJQ05HFjN97C0E6LcyjuOQcFNJMa7E8Q323BJgthsaFBsStTPa IL+/UJ/bG5CUL8yHw6oTFbwm5PYO7OZzQWZdfthmKoN+5ogUGPxQKk2SwykbvViGtpPA OkAn4Cp8j+yGNvFQ8QrUu2QXIophDjvKi2UF8= I was running Erlang which I compiled myself just so that it used my modified FD_SETSIZE. On Apr 15, 2010, at 7:03 PM, Stefan Haller wrote: > Then you may just have been lucky. The Bonjour problem I discribed > occurs whenever you open an NSOpenPanel or NSSavePanel while you are on > a LAN with other Macs. So either this doesn't apply to you, or the code > did overwrite random bits somewhere on your stack and you just didn't > notice. > --- http://es.linkedin.com/in/joelreymont _______________________________________________ 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: Crash with FD_SET when there are more than 1024 open files
by lists＠haller-berlin.de 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haller-berlin.de; s=mail_2009081900; h=Message-ID:Date:From:Subject:In-Reply-To:To; bh=/y7GaFe0HOgJ8aYhqzmLpG8DDpuCVDcSa1wiQS+VMRM=; b=vByXjmZdD9nZ4Cq8Uh4zH/q2WOWSbKsvX6hQNLL84yKFfLqS+iNn75HPXbAPonjFJHMsJKPdS9hboKBqJ1eAPtuZoDSmNmkrcv3ybFl0uC2a285FYwZf5bUgAYryblDJIz1V8s6yvlvRB6q5SRmy8ZobRg41nJ8E8AFM5pkJpog=; User-agent: MacSOUP/2.8.3 (Mac OS X version 10.6.3 (x86)) Joel Reymont <joelr1(a)gmail.com> wrote: > The issue you may have is that Bonjour was compiled with FD_SETSIZE of > 1024. Exactly, that's what I'm talking about. And my concern is that other code may be running in my process that has the same issue (since it's such a common pattern, in the Unix world at least). > I used to routinely open about 50K sockets. Then you may just have been lucky. The Bonjour problem I discribed occurs whenever you open an NSOpenPanel or NSSavePanel while you are on a LAN with other Macs. So either this doesn't apply to you, or the code did overwrite random bits somewhere on your stack and you just didn't notice. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ _______________________________________________ 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: Crash with FD_SET when there are more than 1024 open files
by Joel Reymont 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GAPsFPBWt7atUVQxym2pxWd5OnZUBoLeowJXjE9d94Q=; b=jP22yGzghopfLLdieZPe/NJG2m/K8qNCr0XND0jlyCqIUw4eOTnkcqmpm4uHqP/u5m PkKDnA4W4UNa/LIRDbXr1jO+wC/K3cTjfs/Lo82xXV1lPbL88dv8vHK03jlKmN1LZxZi Wy3sIXuXNBK1eQ5k2l8x9TGj+TMTyT8qmU1Kk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=KbOoKYGyXIqwaJhUUsZ1ZDvK0CYq6MkJYznMcYPHw7pRgFwlKBxDmW6BWbVu72ow28 CtU2waiXzLq2c2uKPTR2eT/bhP4Hn/WB0AXlRwcjHqxVj1wi1FtgHZRktLhPNv8IMqkZ lBujPbGp9D89zMwNCyGjOHpQBGCBYxJVBRCfg= I used to routinely open about 50K sockets. To accomplish this I edited __DARWIN_FD_SETSIZE in /usr/include/sys/_structs.h to set it to a higher number in addition to the following /etc/sysctl.conf kern.maxfiles=102400 kern.maxfilesperproc=40960 net.inet.ip.portrange.hifirst=10000 net.inet.ip.portrange.first=10000 What I found is that Mac OSX was far slower than Linux in this scenario. Search for my name in the archives of this list to read through the lively discussion(s). The issue you may have is that Bonjour was compiled with FD_SETSIZE of 1024. On Apr 15, 2010, at 4:54 PM, Stefan Haller wrote: > We are investigating a reproducible crash that happens in Bonjour code > when we have many files open. The crash happens in > DNSServiceProcessResult (part of mDNSResponder), which contains the > following code: > > static int more_bytes(dnssd_sock_t sd) > { > struct timeval tv = { 0, 0 }; > fd_set readfds; > FD_ZERO(&readfds); > FD_SET(sd, &readfds); > return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); > } > > If sd is greater than 1024, bad things happen; in particular, if sd > happens to be 1669, you get an immediate crash on return from the > function because the code overwrites the saved ebp register. > > See also <rdar://problem/7701369> to which I attached a small example > program that demonstrates the crash. > > Now, this makes me wonder whether it is ever possible, for any > application, to exceed the number of 1024 open files. Even if Apple > fixes that particular piece of code (for example by defining FD_SETSIZE > to a greater value before including <sys/types.h>), other code which we > can't control could have the same problem. That could be OS code, > third-party libraries that we link against, plugins that we load. > > One possible workaround would be to somehow ensure that there's always a > free range of file descriptors below 1024 available for code other than > ours. I wouldn't know how to do that though; any suggestions? > > (We made a quick test to open a hundred dummy files before opening our > real files, and close them right before calling the offending OS > function, in the hope that that the Bonjour code would then use these; > this didn't help though.) > > Thanks, > Stefan > > > -- > Stefan Haller > Berlin, Germany > http://www.haller-berlin.de/ > _______________________________________________ > 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/joelr1%40gmail.com > > This email sent to joelr1(a)gmail.com --- http://es.linkedin.com/in/joelreymont _______________________________________________ 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

Crash with FD_SET when there are more than 1024 open files
by lists＠haller-berlin.de 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haller-berlin.de; s=mail_2009081900; h=Message-ID:Date:From:Subject:To; bh=cLQudhqrUFjgewpheXTJKaLJi9QHTPIebDBtYf9Gzi4=; b=rPcQfwjTtwQsg8QjLx1WN/KiTs2ne4OLwKnTrB9OlkDaZHA6V9vabd9UtKLmPZBI7d9Ahc/lnrPRE063wxuxp4yMGQo+auD8aGS7MdglfVrjIUJktINSLe0AfcbIVdWt31mZJdpVfUpVuAbcfjq5+MDtw+hYfvwGYVkXcCBWa2w=; User-agent: MacSOUP/2.8.3 (Mac OS X version 10.6.3 (x86)) We are investigating a reproducible crash that happens in Bonjour code when we have many files open. The crash happens in DNSServiceProcessResult (part of mDNSResponder), which contains the following code: static int more_bytes(dnssd_sock_t sd) { struct timeval tv = { 0, 0 }; fd_set readfds; FD_ZERO(&readfds); FD_SET(sd, &readfds); return(select(sd+1, &readfds, (fd_set*)NULL, (fd_set*)NULL, &tv) > 0); } If sd is greater than 1024, bad things happen; in particular, if sd happens to be 1669, you get an immediate crash on return from the function because the code overwrites the saved ebp register. See also <rdar://problem/7701369> to which I attached a small example program that demonstrates the crash. Now, this makes me wonder whether it is ever possible, for any application, to exceed the number of 1024 open files. Even if Apple fixes that particular piece of code (for example by defining FD_SETSIZE to a greater value before including <sys/types.h>), other code which we can't control could have the same problem. That could be OS code, third-party libraries that we link against, plugins that we load. One possible workaround would be to somehow ensure that there's always a free range of file descriptors below 1024 available for code other than ours. I wouldn't know how to do that though; any suggestions? (We made a quick test to open a hundred dummy files before opening our real files, and close them right before calling the offending OS function, in the hope that that the Bonjour code would then use these; this didn't help though.) Thanks, Stefan -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ _______________________________________________ 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

Debugging CFBundleLoadExecutable... errors
by Ryan McGann 15 Apr '10

15 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I am using CFBundleLoadExecutableAndReturnError to load a plug-in. When the plug-in fails to load, the errors returned from CFBundle seem to be…not helpful. For example, when it fails to load due to linking issues, I can't seem to find anything in the error report that tells me the symbol that couldn't be found. All I have is the error code (always 3588) and a rudimentary string "The bundle Foo.bundle could not be loaded." Since CoreFoundation calls dlerror internally, I can't call it when CFBundleLoadExecutableAndReturnError fails, and I don't see any other functions I can call to retrieve this info from CFBundle/CFError. (CFErrorCopyDescription, etc. seem to return the same canned strings.) Is there some other way of determining the actual dyld errors that occured without using dlopen()? I can't switch to using dlopen(), as that seems to mess up CFBundle in other ways, but it's a real drag having to call dlopen() whenever CFBundleLoad... fails just so I can retrieve the error information. I tried using the deprecated functions in <mach-o/dyld.h> but those don't return anything useful either. Thanks, Ryan ----------------------- Ryan _______________________________________________ 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: madvise
by Brian Bergstrand 13 Apr '10

13 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Follow the source. For 10.6.3 @ http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/ madvise in bsd/kern/kern_mman.c leads to mach_vm_behavior_set in osfmk/vm/vm_user.c leads to vm_map_behavior_set in osfmk/vm/vm_map.c which appears to implement all the various map operations (in particular DONTNEED and FREE) On Apr 13, 2010, at 11:13 PM, Joel Reymont wrote: > > On Apr 13, 2010, at 8:55 PM, Jonas Maebe wrote: > >> There's this post (on another list) from an Apple engineer: http://lists.apple.com/archives/PerfOptimization-dev/2009/Apr/msg00024.html > > Yes, that's the post I had in mind! > > Can someone clarify the Snow Leopard status of these? > > Thanks, Joel > Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 _______________________________________________ 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: madvise
by Joel Reymont 13 Apr '10

13 Apr '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=NJBGCtHDEHYomi+7+coYYNUugMzirz65bI0z7jssviw=; b=oSaBLuYRgG/spZFyNbwI4kUD/0Xy0t2HLYQ2dotg6G2rZ9Z0oc/lr+db58MaHNoG1p IocAkhGvKvUOWcUSNFOA4jmx5usaK2hEh1EFLf8Ne5uDh4kcEe+UOrAvcZyqaRAnlerG Gye11n0/qlwkGyaoVPgmtuM4PJNNZxT0jp7/g= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=istFtqO9jBT5vhzNnDm1G2cGbK3qsfeYY6BuJissoK93Bk18pTDUduuOLBoWRQwHNC I80OCQebzqUHeWq269G43CWKEiCCDrHVl98oGh4P+RNBr/v3gQuxEq/B+5jfrhQy3AdH Jd05CrgimHK+FekppMFcZyNDX40MGi+rbi2KI= On Apr 13, 2010, at 8:55 PM, Jonas Maebe wrote: > There's this post (on another list) from an Apple engineer: http://lists.apple.com/archives/PerfOptimization-dev/2009/Apr/msg00024.html Yes, that's the post I had in mind! Can someone clarify the Snow Leopard status of these? Thanks, Joel --- http://es.linkedin.com/in/joelreymont _______________________________________________ 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