POLLHUP/POLERR may be returned anytime (per POSIX, these flags aren't
even valid in input flags, they just appear in output flags). Subsequent
I/O operation on stream will lead to exception. If an application
doesn't do proper exception handling, the stream won't be closed, and
following calls will return POLLHUP/POLLERR status again (infinitely).
So, proactively unregister such a stream.
This change is questionable, because apps should handle errors properly
and close the stream in such case (or it will be leaked), and closing
will remove the stream from poller too.
But again, if that's not done, it may lead to cascade of adverse effects,
e.g. after eef054d98, benchmark/test_http_server_heavy.py regressed and
started and started to throw utimeq queue overflow exceptions. The story
behind it is: Boom benchmarker does an initial probe request to the app
under test which it apparently doen't handle properly, leading to
EPIPE/ECONNRESET on the side of the test app, the app didn't close the
socket, so each invocation to .wait() resulted in that socket being
returned with POLLHUP again and again. Given that after eef054d98, .wait()
is called on each even loop iteration, that create positive feedback in
the queue leading to it growing to overflow.
micropython-lib is a project to develop a non-monolothic standard library
for MicroPython (https://github.com/micropython/micropython). Each module
or package is available as a separate distribution package from PyPI. Each
module comes from one of the following sources (and thus each module has
its own licensing terms):
written from scratch specifically for MicroPython
ported from CPython
ported from some other Python implementation, e.g. PyPy
some modules actually aren't implemented yet and are dummy
Note that the main target of micropython-lib is a "Unix" port of MicroPython.
Actual system requirements vary per module. For example, if a module is not
related to I/O, it may work without problems on bare-metal ports too (e.g.
pyboard).
Usage
micropython-lib packages are published on PyPI (Python Package Index),
the standard Python community package repository: http://pypi.python.org/ .
On PyPI, you can search for MicroPython related packages and read
additional package information. By convention, all micropython-lib package
names are prefixed with "micropython-" (the reverse is not true - some
package starting with "micropython-" aren't part of micropython-lib and
were released by 3rd parties).
To install packages from PyPI for usage on your local system, use the
upip tool, which is MicroPython's native package manager, similar to
pip, which is used to install packages for CPython. upip is bundled
with MicroPython "Unix" port (i.e. if you build "Unix" port, you
automatically have upip tool). Following examples assume that
micropython binary is available on your PATH:
$ micropython -m upip install micropython-pystone
...
$ micropython
>>> import pystone
>>> pystone.main()
Pystone(1.2) time for 50000 passes = 0.534
This machine benchmarks at 93633 pystones/second
Run micropython -m upip --help for more information about upip.
Development
To install modules during development, use make install. By default, all
available packages will be installed. To install a specific module, add the
MOD=<module> parameter to the end of the make install command.
Links
If you would like to trace evolution of MicroPython packaging support,
you may find following links useful (note that they may contain outdated
information):
f81285ff4e