Message137889
| Author |
sdaoden |
| Recipients |
ixokai, nadeem.vawda, ned.deily, neologix, pitrou, python-dev, sdaoden, skrah, vstinner |
| Date |
2011年06月07日.22:14:13 |
| SpamBayes Score |
7.2164497e-16 |
| Marked as misclassified |
No |
| Message-id |
<20110607221322.GA28023@sherwood.local> |
| In-reply-to |
<1307468619.94.0.757287865085.issue11277@psf.upfronthosting.co.za> |
| Content |
@ Ned Deily <report@bugs.python.org> wrote (2011年06月07日 19:43+0200):
> Thanks for the update. Since the fix will be in a future
> version of OS X 10.7 Lion, and which has not been released yet,
> so it is not appropriate to change mmap until there has been an
> opportunity to test it.
It's really working fine. That i see that day!
(Not that they start to fix the CoreAudio crashes...)
> But even then, we would need to be careful about adding
> a compile-time test as OS X binaries are often built to be
> compatible for a range of operating system version so avoid
> adding compilation conditionals unless really necessary.
> If after 10.7 is released and someone is able to test that it
> works as expected, the standard way to support it would be to
> use the Apple-supplied availability macros to test for the
> minimum supported OS level of the build assuming it makes enough
> of a performance difference to bother to do so
Of course it only moves the delay from before mmap(2) to after
close(2). Well, i don't know, if hardcoding is not an option,
a dynamic sysctl(2) lookup may do:
kern.version = Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011
This is obviously not the right one. :)
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments |
|