Boost logo

Boost :

Subject: Re: [boost] [AFIO] Formal review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-09-01 01:34:03

On 1/09/2015 04:18, Niall Douglas wrote:
>> - The documentation notes: "Don't do directory enumerations from an x86 binary
>> on a x64 Windows system. This is due to a bug in Microsoft's WOW64 syscall
>> translation layer which Microsoft have decided is wontfix. " Given that a
>> major purpose of AFIO is to provide a portable abstraction that works around
>> OS limitations, AFIO needs to support directory enumeration even in this case
>> (e.g. by detecting WOW64 and using a synchronous call via a threadpool in that
>> case).
> This problem is caused by how ASIO's reactor works and is due to code
> I can't modify in ASIO. It'll go away when I rewrite ASIO's reactor
> using lightweight futures because I can control the source code.

The suggestion was that you explicitly detect the problem case (ie.
running under WOW64) and then execute an alternate enumeration codepath
in that case (avoid the problem API and call a different one, perhaps
synchronously). I'm not sure how ASIO's reactor bears any relationship
to this.

If the problem is that you need to call a synchronous API, then note
that you can queue up work via the common threadpool reactor that
actually executes synchronously on a dedicated worker thread, or pool
thereof (ASIO even does this itself internally for some things, where
async APIs are not available). It's a little less efficient, of course,
but not particularly difficult.

If it's not about synchrony, then presumably you need to call the Win32
API instead of the Native API in this case. So do that.

It's not acceptable to simply say "directory enumeration doesn't work in
32-bit Windows processes sometimes". That's a bug, and even if MS
agreed to fix it you would still have to have code that worked around it
on versions before the fix.

> AFIO fatal exits the process if you try to read or write past the
> current file size, it's a logic error and your program is inherently
> broken.

FWIW, any library choosing to fatal exit the process for ANY reason
causes me to fatally exit the library (ie. not use it), particularly if
it doesn't provide interception hooks.

My apps have their own methods for reacting to fatal errors of any kind
(mostly unified logging and graceful exit) and I don't appreciate
anything that tries to bypass them. (In fact I have some code
specifically dedicated to preventing the VC++ CRT from trying to bypass
the error handler.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at