0a529adfdc
When we issue IORead/IOWrite syscall, we want get back notification just for that call. But if we add fd to epoll, it will trigger continuously when the condition is met. For example, a socket with empty write buffer will always signal EPOLLOUT, regardless if we want to write to it now or not. This will lead to situation when our coro will be woken up on such socket on *any* syscall, and this syscall will get completely different socket as result ( or if syscall doesn't return socket - completely different result value). So, to get semantics right, we need to make sure that for each IORead/IOWrite, we get notified only once, and further events on socket are ignored until we ask for them again. This is exactly what EPOLLONESHOT flag does. The other alternative is to remove fd from epoll after each IORead/IOWrite, but apparently EPOLLONESHOT is more performant way. Yet another alternarnative would be to use edge-triggered mode of epoll, but it has own peculiarities, like, after each event, client must make sure that it is handled completely and reset, otherwise it may not trigger again, even if there's unprocessed data. For example, if EPOLLIN|EPOLLET is used, client must make sure that it reads all data available, until read() returns EAGAIN. If it reads say just 10 bytes, then next time event simply won't trigger (because it's edge event, which triggers on change like "no data" - "data"; if we didn't read all data, the situation is "data" - "data", there's no change in condition, and event is not triggered). Surely, that's not what we want (at least not without restructuring how StreamReader works). So, EPOLLONESHOT is the most obvious, and easiest to reason way to get needed semantics. |
||
|---|---|---|
| _libc | ||
| abc | ||
| asyncio_slow | ||
| base64 | ||
| binascii | ||
| binhex | ||
| bisect | ||
| calendar | ||
| cmd | ||
| collections | ||
| collections.defaultdict | ||
| collections.deque | ||
| copy | ||
| csv | ||
| datetime | ||
| dbm | ||
| email.charset | ||
| email.encoders | ||
| email.errors | ||
| email.feedparser | ||
| email.header | ||
| email.internal | ||
| email.message | ||
| email.parser | ||
| email.utils | ||
| errno | ||
| fcntl | ||
| fnmatch | ||
| functools | ||
| getopt | ||
| getpass | ||
| glob | ||
| gzip | ||
| hashlib | ||
| heapq | ||
| html/html | ||
| html.entities | ||
| http.client | ||
| io | ||
| ipaddress | ||
| itertools | ||
| json | ||
| keyword | ||
| logging | ||
| mailbox | ||
| mimetypes | ||
| multiprocessing | ||
| optparse | ||
| os | ||
| os.path | ||
| pickle | ||
| posixpath | ||
| pprint | ||
| pty | ||
| queue | ||
| quopri | ||
| random | ||
| re-pcre | ||
| reprlib | ||
| sched | ||
| select | ||
| shelve | ||
| shlex | ||
| shutil | ||
| socket | ||
| sqlite3 | ||
| stat | ||
| string | ||
| subprocess | ||
| tarfile | ||
| tempfile | ||
| test.pystone | ||
| test.support | ||
| timeit | ||
| traceback | ||
| types | ||
| uasyncio | ||
| uasyncio.core | ||
| unittest | ||
| urllib | ||
| urllib.parse | ||
| uu | ||
| warnings | ||
| zipfile | ||
| .gitignore | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| make_metadata.py | ||
README.md
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
micropython-lib is a highly experimental community project.
Please help to drive it to just "experimental" state by testing
provided packages with MicroPython.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
micropython-lib
micropython-lib is a project to develop a non-monolothic standard library for MicroPython. Each module or package is available as a separate distribution package from PyPI. Each module is either written from scratch or ported from CPython.
Note that the main target of micropython-lib is a "Unix" port of MicroPython (additional ports to support are to be determined). Actual system requirements vary per module. Though if a module is not related to I/O, the module should work without problem 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.
To install packages from PyPI for usage on your local system, use the
pip-micropython tool, which is a simple wrapper around the standard
pip tool, which is used to install packages for CPython.
The pip-micropython tool can be found in tools subdirectory
of the main MicroPython repository (https://github.com/micropython/micropython).
Just install the pip-micropython script somewhere on your PATH.
Afterwards, just use pip-micropython in a way similar to pip:
$ pip-micropython install micropython-copy
$ micropython
>>> import copy
>>> copy.copy([1, 2, 3])
[1, 2, 3]
Review the pip-micropython source code for more info.
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
More information is on GitHub and in the MicroPython forums:
- https://github.com/micropython/micropython/issues/405
- http://forum.micropython.org/viewtopic.php?f=5&t=70
Guidelines for packaging MicroPython modules for PyPI: