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/2014-September/136137.html below:

[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTRAntoine Pitrou solipsis at pitrou.net
Mon Sep 1 14:58:18 CEST 2014
Hi,

I'm +1 on the whole PEP.

> Writing a signal handler is difficult, only "async-signal safe"
> functions can be called.

You mean a C signal handler? Python signal handlers are not restricted.

> Some signals are not interesting and should not interrupt the the
> application.  There are two options to only interrupt an application
> on some signals:
> 
> * Raise an exception in the signal handler, like ``KeyboardInterrupt`` for
>   ``SIGINT``
> * Use a I/O multiplexing function like ``select()`` with the Python
>   signal "wakeup" file descriptor: see the function
>   ``signal.set_wakeup_fd()``.

This section looks a bit incomplete. Some calls such as os.read() or
os.write() will (should) return a partial result when interrupted and
they already handled >0 bytes. Perhaps other functions have a similar
behaviour?

> On Unix, the ``asyncio`` module uses the wakeup file descriptor to
> wake up its event loop.

How about Windows?

Regards

Antoine.


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