Message148180
| Author |
sbt |
| Recipients |
brian.curtin, jnoller, pitrou, python-dev, sbt, tim.golden |
| Date |
2011年11月23日.11:44:21 |
| SpamBayes Score |
2.7228658e-08 |
| Marked as misclassified |
No |
| Message-id |
<1322048662.68.0.632615343915.issue12328@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> I have the feeling that if we have to call GetLastError() at the
> Python level, then there's something wrong with the APIs we're
> exposing from the C extension.
> I see you check for ERROR_OPERATION_ABORTED. Is there any situation
> where this can happen?
There are three "expected" error conditions:
ERROR_OPERATION_ABORTED: operation stopped by CancelIo(Ex)()
ERROR_MORE_DATA: operation complete, but only got part of the message
ERROR_IO_INCOMPLETE: operation still has not finished
In the win32 api you need GetLastError() to distinguish between these cases, but maybe we can expose something better.
> Also, it seems strange to call ov.cancel() and then
> ov.GetOverlappedResult(). AFAICT, those two operations should be
> mutually exclusive: you call the former if e.g. WaitForMultipleObjects
> raised an exception, the latter otherwise.
If WaitForMultipleObjects() returns WAIT_OBJECT_0 + 0 then, as you say, there is no need to call ov.cancel(), but it is harmless to call it if the operation has already completed.
The cases aren't really mutually exclusive: if you call ov.cancel() you *must* still do ov.GetOverlappedResult(True) to check for the race where the operation completes after the wait times out, but before ov.cancel() can stop it. (Your original implementation had that bug -- see point (5) in my original bug report.) |
|