Dear Guido, Thanks for your fast reply. I have never contributed to the Python project before. A quick look at the relevant modules seems to indicate that I'll probably have to touch quite a few classes in both the selectors and asyncio modules, but the changes should be quite simple. The case for asyncore was (obviously) a lot simpler...
Here's one of the examples where I've extended asyncore, to illustrate what I mean: https://github.com/yope/grunner/blob/master/gpio.py The original code as contained in the ayncore-library would put any read- or write file-descriptor also into the exception set, but I needed a way to add it _only_ to exception and not any of the two others. The special file /sys/class/gpio/<name>/value in Linux is _always_ ready for reading/writing, but will generate an "exception" event that makes select.select return with the FD added to the third list (called xlist) or select.poll with POLLPRI/POLLERR if the content changes according to the trigger set in the /sys/class/gpio/<name>/edge. For embedded systems (and obviously for the raspberry-pi and similar kits) this is actually pretty nifty functionality. This functionality should also be useful for certain TCP/IP socket code and AFAIK also for some V4L devices, although I have not seen it used in python-code. At my work, we are currently deciding about moving python-2.7 based code that uses asyncore in a similar way to python-3.4 with asyncio, and knowing that there are chances we can get this change into mainline Python with blessings from the master himself, could actually make this transition happen :-) Expect to see patches from either me or someone else once we start the porting work. Any hint about the proper procedure in submitting for a first-time contributor is appreciated. Best regards, 2014-09-25 18:33 GMT+02:00 Guido van Rossum <gu...@python.org>: > It's totally fine to submit patches for this. I have never seen a use case > for this in my life, but I am glad that you have one! > > On Thu, Sep 25, 2014 at 8:05 AM, David Jander <djan...@gmail.com> wrote: > >> >> Hi all, >> >> I have been using asyncore until now, and am very excited about the new >> asyncio library, but there is one thing I have always missed on asyncore >> (although it was halfway there) which does not seem to be possible with >> asyncio (please correct me if I'm wrong): >> >> On UNIX (Linux) the selectors module is specially powerful, since not >> only sockets can be used, but this extra power is crippled by the fact that >> there is no support (apparently) for select.select "exceptional condition" >> lists, or for select.poll "POLLPRI or POLLERR" events. I can imagine that >> the use-cases of these are a big mystery to many and probably few people >> actually know what they're for. >> >> When using asyncore I usually extend the module by replacing the poll() >> function with my own version that supports "exceptional condition"-only >> dispatchers. These are very useful when dealing with direct character- and >> sysfs-device access on (embedded-)Linux systems for example. >> >> One such example is the Linux GPIO sysfs interface. (see >> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt for more info). >> Via this interface, one can manipulate digital input/output signals >> directly from user-space. One exceptionally (no pun intended) cool feature >> is the possibility of using inputs to trigger "software interrupts" in >> user-space via select() or poll(). >> >> Probably this functionality would have to be implemented in the selectors >> module first by means of support for EVENT_EXCEPTION in addition to >> EVENT_READ and EVENT_WRITE. >> >> What about adding support for this to python selectors and asyncio? Would >> patches for something like this be accepted or is this out of the question? >> >> Best regards, >> >> > > > -- > --Guido van Rossum (python.org/~guido) > -- David Jander
