On Oct 19, 2010, at 8:09 PM, James Y Knight wrote: > There's a difference. > > os._exit is useful. os.open is useful. aio_* are *not* useful. For anything. > If there's anything you think you want to use them for, you're wrong. It > either won't work properly or it will worse performing than the simpler > alternatives.
I'd like to echo this sentiment. This is not about providing a 'safe' wrapper to hide some powerful feature of these APIs: the POSIX aio_* functions are really completely useless. To quote the relevant standard <http://www.opengroup.org/onlinepubs/000095399/basedefs/aio.h.html>: APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. Not only is the performance usually worse than expected, the behavior of aio_* functions require all kinds of subtle and mysterious coordination with signal handling, which I'm not entirely sure Python would even be able to pull off without some modifications to the signal module. (And, as Jean-Paul mentioned, if your OS kernel runs out of space in a queue somewhere, completion notifications might just never be delivered at all.) I would love for someone to prove me wrong. In particular, I would really love for there to be a solution to asynchronous filesystem I/O better than "start a thread, read until you block". But, as far as I know, there isn't, and wrapping these functions will just confuse and upset anyone who attempts to use them in any way.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
