On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum wrote:
> I don't have a strong opinion on this either. The distinction between
> send() and send_all() makes sense to me though (send_all() works hard to
> get all your data out, send() only does what it can quickly).
>
> Personally for calls lik
I don't have a strong opinion on this either. The distinction between
send() and send_all() makes sense to me though (send_all() works hard to
get all your data out, send() only does what it can quickly).
Personally for calls like select() I think returning early on EINTR makes
sense, it's usually
On Fri, 30 Aug 2013 12:29:12 +0200
Charles-François Natali wrote:
>
> Furthermore, the stdlib code base is not consistent: some code paths
> handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does
> but not sock_send()...
> Just grep for EINTR and InterruptedError and you'll be amazed
2013/8/30 Amaury Forgeot d'Arc :
> I agree.
> Is there a way to see in C code where EINTR is not handled?
EINTR can be returned on slow syscalls, so a good heuristic would be
to start with code that releases the GIL.
But I don't see a generic way apart from grepping for syscalls that
are documente
On 30 August 2013 20:29, Charles-François Natali wrote:
> Hello,
>
> This has been bothering me for years: why don't we properly handle
> EINTR, by running registered signal handlers and restarting the
> interrupted syscall (or eventually returning early e.g. for sleep)?
>
> EINTR is really a nuis
2013/8/30 Charles-François Natali
> Hello,
>
> This has been bothering me for years: why don't we properly handle
> EINTR, by running registered signal handlers and restarting the
> interrupted syscall (or eventually returning early e.g. for sleep)?
>
> EINTR is really a nuisance, and exposing it
