homepage

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 gregory.p.smith, gvanrossum, pitrou, sbt, vstinner
Date 2013年08月31日.17:00:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377968398.2478.37.camel@fsol>
In-reply-to <1377967453.52.0.267894749348.issue18885@psf.upfronthosting.co.za>
Content
> FWIW, there are times when we *want* the interrupted system call to
> return control to Python rather than retrying the call.
I'm a bit curious, do you know of any use cases?
> If someone is making a Python equivalent of the low level system call
> such as select() or poll(), the EINTR should be exposed for Python
> code to handle.
As mentioned in another issue, you would use a special wakeup fd to
wakeup select() or poll() calls.
> Getting an EINTR errno does *not* mean you can simply retry the system
> calls with the exact same arguments. ie: If you did that with the
> select() call within time.sleep it'd be trivial to make the process
> sleep forever by sending it signals with a frequency less than the
> sleep time.
Indeed. That's already done in e.g. socketmodule.c : take a look at the
BEGIN_SELECT_LOOP / END_SELECT_LOOP macros.
History
Date User Action Args
2013年08月31日 17:00:14pitrousetrecipients: + pitrou, gvanrossum, gregory.p.smith, vstinner, sbt
2013年08月31日 17:00:14pitroulinkissue18885 messages
2013年08月31日 17:00:14pitroucreate

AltStyle によって変換されたページ (->オリジナル) /