This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12/11/2012 08:13 PM, Daniel Colascione wrote: > On 12/11/2012 5:06 PM, Daniel Colascione wrote: >> On 12/10/2012 7:51 PM, Daniel Colascione wrote: >>> The key to generating a binary that repros the problem is to unexec emacs, then >>> try to repro with that generated binary, not a copy of it. >> >> The real explanation is a lot simpler: the binary is sparse. When you create a >> file mapping object for a sparse file, Windows discards all cached pages for >> that file. It makes sense that compilers (and Emacs unexec) would create sparse >> files as they seek around inside their outputs. > > Anyway, the binary is sparse because our linker produces sparse files. > > Would the Cygwin developers accept this patch? With it, applications would need > to explicitly use ftruncate to make files sparse. Eww. That would be a regression for coreutils, and a waste of disk space for files where sparse is a benefit. > Considering the horrible and > unexpected performance implications of sparse files, I don't think generating > them automatically from a sequence of seeks and writes is the right thing to do. Why can't we instead use posix_fallocate() as a means of identifying a file that must not be sparse, and then just patch the compiler to use posix_fallocate() to never generate a sparse executable (but let all other sparse files continue to behave as normal)? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |