| |||||||||||||
A proposal for "rebooted" Python asynchronous I/O supportA proposal for "rebooted" Python asynchronous I/O supportPosted Dec 30, 2012 0:33 UTC (Sun) by ppisa (subscriber, #67307)Parent article: A proposal for "rebooted" Python asynchronous I/O support
I like proposal and please, invest time to to ensure good compatibility with libevent-2 main loop and consider even its buffer events. I think that that library is good candidate for generic mainloop for most of applications.
But there is need to live with GLIB based mainloop as well. Its interface is so rigid and unfortunate that only option for other GUI systems (like Qt) was to switch to GLIB mainloop when GLIB based loop libraries are considered for them. I hope that GLIB community would invest time to that problem some day but it cannot be done without API level compatibility break.
You can look at my ul_evpoll effort as a source for some ideas too. It started in libevent-1 days as an solution to write libraries requiring system level events registration and compatibility with GLIB and yet to be able to switch to libevent. Then the project little extended to provide own implementation of select, poll, epoll and winevent mechanism and ability to plug-in into GLIB, libevent-1 and libevent-2 based applications.
The ul_evpoll library is part of uLAN and OrtCAN SF.net repositories
(Log in to post comments)
A proposal for "rebooted" Python asynchronous I/O support Posted Jan 5, 2013 19:53 UTC (Sat) by cmccabe (guest, #60281) [Link] 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.
|
|||||||||||||