A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-May/065262.html below:

[Python-Dev] epoll implementation

[Python-Dev] epoll implementation [Python-Dev] epoll implementation"Martin v. Löwis" martin at v.loewis.de
Fri May 26 22:27:14 CEST 2006
> How about "not *only* as a separate set of calls"?  If poll(2) and
> epoll(4) are both available on the underlying platform, then they
> should both be exposed to Python as separate APIs.  Then, on top of
> that, a relatively simple layer which selects the most efficient
> mechanism can be exposed, and developers can be encouraged to use
> that instead.

Why does it have to be a separate API? Isn't the edge-triggered
mode just a matter of passing EPOLLET into register?

If so, I would advise against having two sets of functions,
although having two sets of constants is propably fine.
I would just provide a second constructor, select.epoll(),
which guarantees that epoll is used as the implementation
strategy (i.e. it would raise OSError if the kernel doesn't
support epoll_create).

Regards,
Martin

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4