This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brian.curtin, christian.heimes, exarkun, giampaolo.rodola, gvanrossum, jkloth, mhammond, pitrou, sbt
Date 2012-10-09.21:16:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349817281.3334.11.camel@localhost.localdomain>
In-reply-to <1349816980.27.0.461143358461.issue16175@psf.upfronthosting.co.za>
Content
> According to http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%
> 29.aspx once you call GetQueuedCompletionStatus() your thread is
> managed by the IOCP and only up to a given parameter of those threads
> are allowed to run.  They recommend setting that parameter to the
> number of CPUs.  This feels scary (doubly so in the light of the GIL).

I think this mostly means that you should always call
GetQueuedCompletionStatus() from the same thread for a given IO
completion port. Which, in the context of a single-threaded event loop,
shouldn't be a problem (also, this can be enforced by our stdlib
wrapper).

AFAIU, the MSDN docs have this complicated language about threads mostly
because they suggest you to use as many threads as there are CPUs on the
machines (in order to max out the I/O processing bandwidth).

By the way, I've just checked: the Twisted IOCP reactor uses a single
I/O completion port to which it registers all socket handles, and its
event loop calls GetQueuedCompletionStatus() in a loop.
History
Date User Action Args
2012-10-09 21:16:12pitrousetrecipients: + pitrou, gvanrossum, mhammond, exarkun, giampaolo.rodola, christian.heimes, jkloth, brian.curtin, sbt
2012-10-09 21:16:12pitroulinkissue16175 messages
2012-10-09 21:16:11pitroucreate