Re: [boost] [AFIO] Formal review

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.)