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 vstinner
Recipients gvanrossum, loewis, neologix, pitrou, python-dev, vstinner, yselivanov
Date 2014-07-25.12:52:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406292752.96.0.155996913138.issue22018@psf.upfronthosting.co.za>
In-reply-to
Content
Charles-François wrote:

> I don't think we should set it non-blocking automatically, but rather
check that it's non-blocking.
> The first reason I can think of is that the user passing a blocking FD
could be a sign of a bug (e.g. if the other end is in blocking mode
too), and we shouldn't silently work-around it.

I hesitate between making the file descriptor non-blocking or raise an exception if it configured in blocking mode. Since I have no experience on such question, I prefer to follow your advices :-) So raise an exception if the FD is blocking.

It doesn't answer to my complain: I don't want to support file descriptors on Windows anymore because file descriptors cannot be configured in non-blocking mode.

If we raise an error if FD and sockets are blocking, calling set_wakeup_fd() on a FD on Windows would always fail. So raising an exception because the integer is a file descriptor or raising an exception because the file descriptor is blocking leads to same result: FD are not more supported on Windows.

What do you think?
History
Date User Action Args
2014-07-25 12:52:33vstinnersetrecipients: + vstinner, gvanrossum, loewis, pitrou, neologix, python-dev, yselivanov
2014-07-25 12:52:32vstinnersetmessageid: <1406292752.96.0.155996913138.issue22018@psf.upfronthosting.co.za>
2014-07-25 12:52:32vstinnerlinkissue22018 messages
2014-07-25 12:52:32vstinnercreate