From: Kalle Olavi Niemitalo on
nmm1(a)cam.ac.uk writes:

> See the specification of aio_read: "For any system action that changes
> the process memory space while an asynchronous I/O is outstanding to the
> address range being changed, the result of that action is undefined."

To me, changing "the process memory space" suggests mmap-like
operations that change the space itself rather than just write to
the memory in it. In which case, the outstanding asynchronous
I/O might keep using the original mapping or not. Although the
spec also says the behavior is undefined if the related address
ranges become illegal addresses, that does not cover mapping a
different file on a page that had already been mapped.

Of course, I may have entirely misunderstood the wording.
From: nmm1 on
In article <87y6csnfdz.fsf(a)Pulska.kon.iki.fi>,
Kalle Olavi Niemitalo <kon(a)iki.fi> wrote:
>
>> See the specification of aio_read: "For any system action that changes
>> the process memory space while an asynchronous I/O is outstanding to the
>> address range being changed, the result of that action is undefined."
>
>To me, changing "the process memory space" suggests mmap-like
>operations that change the space itself rather than just write to
>the memory in it. In which case, the outstanding asynchronous
>I/O might keep using the original mapping or not. Although the
>spec also says the behavior is undefined if the related address
>ranges become illegal addresses, that does not cover mapping a
>different file on a page that had already been mapped.

That is certainly possible, and I wondered about that possibility.
If it IS the intention, then POSIX contains no constraints on even
writing to a buffer while data are being read into it asynchronously.
Anyone With Clue will know that is undefined behaviour, but ....

My basic point isn't about what it says but that the specification
is such a mess that it is unusable in portable, reliable programs.
There are a LOT of areas in POSIX that are like that :-(


Regards,
Nick Maclaren.