I agree that this is a fragile assertion; it's too far removed from the
CreateFileMapping call which can generate it and almost impossible to
work around (in calling code) if it should fail in the way we're seeing
in the buildbot.

I think we're better off relying on a genuine exception bubbling up from
the CreateFileMapping/MapViewOfFile calls than trying to assert the
no-exception error return.

While the "preallocate self.buffer" hack you mention would probably have
the effect of preventing the assertion, it's really just adding another
layer of unwanted complexity. (And might still not work in some future
memory-allocation algorithm).

@Richard: if you're watching, have I missed anything?