Karsten Blees <karsten.blees <at> gmail.com> writes:
> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
> > On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager <szager <at> google.com>
> >> On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund <kusmabite <at>
> >>> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager <szager <at> google.com>
> >>>> I don't want to steal the thunder of my coworker, who wrote the
> >>>> implementation. He plans to submit it upstream soon-ish. It relies
> >>>> on using the lpOverlapped argument to ReadFile(), with some
> >>>> tomfoolery to make sure that the implicit position pointer for the
> >>>> file descriptor doesn't get modified.
> >>> Is the code available somewhere? I'm especially interested in the
> >>> "additional tomfoolery to make sure that the implicit position pointer
> >>> for the file descriptor doesn't get modified"-part, as this was what I
> >>> ended up butting my head into when trying to do this myself.
> >> https://chromium-review.googlesource.com/#/c/186104/
> > ReOpenFile, that's fantastic. Thanks a lot!
> ...but should be loaded dynamically via GetProcAddress, or are we ready to
drop XP support?
Original patch author here. In trying to prepare this patch to use
GetProcAddress to load dynamically, I've run into a bit of a snag.
NO_THREAD_SAFE_PREAD is a compile-time flag, which will be incompatible with
any attempt to make this a runtime decision a la LoadLibrary /
GetProcAddress. On XP, we would need to fallback to the single-threaded
path, and on Vista+ we would use the thread-able path, and obviously this
decision could not be made until runtime.
If MinGW were the only configuration using NO_THREAD_SAFE_PREAD, I would
just remove it entirely, but it appears Cygwin configuration uses it also.
One possibility is to disallow (by convention, perhaps), the use of pread()
and read() against the same fd. The only reason ReOpenFile is necessary at
all is because some code somewhere is mixing read-styles against the same
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html