A proposal for "rebooted" Python asynchronous I/O support
Posted Jan 5, 2013 19:53 UTC (Sat) by cmccabe
In reply to: A proposal for "rebooted" Python asynchronous I/O support
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.
to post comments)