| |||||||||||||
A proposal for "rebooted" Python asynchronous I/O supportA proposal for "rebooted" Python asynchronous I/O supportPosted Jan 5, 2013 19:53 UTC (Sat) by cmccabe (guest, #60281)In reply to: A proposal for "rebooted" Python asynchronous I/O support by ppisa Parent article: A proposal for "rebooted" Python asynchronous I/O support From the libabc readme:
> Avoid thinking about main loops/event dispatchers. > - Get your stuff right in the kernel: fds are awesome, expose them > in userspace and in the library, because people can easily integrate > them with their own poll() loops of whatever kind they have. > - Don't hide file descriptors away in your headers. > - Never add blocking kernel syscalls, and never add blocking library > calls either (with very few exceptions). Userspace code is primarily > asynchronous around event loops, and blocking calls are generally > incompatible with that. > - Corollary of that: always O_NONBLOCK!I can't think of any library I have used in the past few years that has used a glib-based main loop. So basically, if your library depends on some event loop framework... you're doing it wrong.
(Log in to post comments)
|
|||||||||||||