Message113997
| Author |
pitrou |
| Recipients |
brian.curtin, loewis, pitrou, tim.golden |
| Date |
2010年08月15日.19:05:36 |
| SpamBayes Score |
1.3133938e-12 |
| Marked as misclassified |
No |
| Message-id |
<1281899134.3194.15.camel@localhost.localdomain> |
| In-reply-to |
<4C6837B4.10309@v.loewis.de> |
| Content |
Le dimanche 15 août 2010 à 18:53 +0000, Martin v. Löwis a écrit :
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> > Well, the loop stops when an error status is returned by the raw IO
> > layer. At that point, the buffered IO layer re-raises the error after a
> > bit of internal cleanup.
>
> Assume the following case:
> 1. writing starts, and writes some data
> 2. Ctrl-C is pressed, raises a signal, and interrupts the current
> system call (EINTR)
> 3. having already written data, the signal is discarded, and the
> number of successfully written bytes is returned.
> 4. the loop retries to write the rest. Not receiving any signal
> anymore, the subsequent write operations wait for completion.
Ok, I guess the loop should run PyErr_CheckSignals() somewhere.
Simulate such a situation in an unit test will be a bit tricky.
Perhaps we can use os.pipe() and depend on the fact that writes greater
than the pipe buffer size will be blocking. |
|