On Fri, May 30, 2014 at 4:15 AM, Heikki Linnakangas <hlinnakan...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers