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 sbt
Recipients giampaolo.rodola, gvanrossum, jcea, neologix, pitrou, sbt, trent
Date 2013-01-21.18:40:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <50FD8B93.8030407@gmail.com>
In-reply-to <1358789930.53.0.0249198701676.issue16507@psf.upfronthosting.co.za>
Content
On 21/01/2013 5:38pm, Guido van Rossum wrote:
> This is a very good question to which I have no good answer.
> If it weren't for this, we could probably do away with the distinction
> between add_writer and add_connector, and a lot of code could be
> simpler.  (Or is that distinction also needed for IOCP?)

The distinction is not needed by IOCP.  I am also not too sure that 
running tulip on WSAPoll() is a good idea, even if the select module 
provides it.

OFF-TOPIC: Although it is not the optimal way of running tulip with 
IOCP, I have managed to implement IocpSelector and IocpSocket classes 
well enough to pass tulip's unittests (except for the ssl one).

I did have to make some changes to the tests: selectors have a 
wrap_socket() method which prepares a socket for use with the selector. 
  On Unix it just returns the socket unchanged, whereas for IocpSelector 
it returns an IocpSocket wrapper.

I also had to make the unittests behave gracefully if there is a 
"spurious wakeup", i.e. the socket is reported as readable, but trying 
to read fails with BlockingIOError.  (Spurious wakeups are possible but 
very rare with select() etc.)

It would be possible to make IocpSelector deal with pipe handles too.
History
Date User Action Args
2013-01-21 18:40:31sbtsetrecipients: + sbt, gvanrossum, jcea, pitrou, giampaolo.rodola, trent, neologix
2013-01-21 18:40:31sbtlinkissue16507 messages
2013-01-21 18:40:31sbtcreate