On Fri, May 30, 2014 at 4:15 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
>>>> We don't want polling... And even if we did, calling aio_suspend() in a
>>>> way
>>>> that's known to be broken, in a loop, is a pretty crappy way of polling.
>>
>>
>> Well, as mentioned earlier, it is not broken. Whether it is
>> efficient I am not sure.
>> I have looked at the mutex in aio_suspend that you mentioned and I am not
>> quite convinced that, if caller is not the original aio_read process,
>> it renders the suspend() into an instant timeout. I will see if I can
>> verify that.
>
>
> I don't see the point of pursuing this design further. Surely we don't want
> to use polling here, and you're relying on undefined behavior anyway. I'm
> pretty sure aio_return/aio_error won't work from a different process on all
> platforms, even if it happens to work on Linux. Even on Linux, it might stop
> working if the underlying implementation changes from the glibc pthread
> emulation to something kernel-based.
I'll try to do some measuring of performance with:
a) git head
b) git head + patch as-is
c) git head + patch without aio_suspend in foreign processes (just re-read)
d) git head + patch with a lwlock (or whatever works) instead of aio_suspend
a-c will be the fastest, d might take some while.
I'll let you know of the results as I get them.