Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #19801

Re: python reliability with EINTR handling in general modules

Path csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path <python-python-list@m.gmane.org>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.000
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; 'handler': 0.04; '>in': 0.07; 'app,': 0.07; 'python': 0.08; 'default.': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'runtime': 0.09; 'subject:modules': 0.09; 'url:faq': 0.09; 'subject:python': 0.10; 'exception': 0.12; 'library': 0.13; 'processor': 0.15; 'bieber': 0.16; 'email addr:ix.netcom.com': 0.16; 'email name:wlfraed': 0.16; 'from:addr:ix.netcom.com': 0.16; 'from:addr:wlfraed': 0.16; 'from:name:dennis lee bieber': 0.16; 'message-id:@4ax.com': 0.16; 'oleg': 0.16; 'received:wlfraed': 0.16; 'redundant,': 0.16; 'solution?': 0.16; 'subject:handling': 0.16; 'translates': 0.16; 'url:netcom': 0.16; 'url:wlfraed': 0.16; 'valueerror': 0.16; 'wulfraed': 0.16; 'wrote:': 0.16; 'wed,': 0.17; 'help.': 0.18; "haven't": 0.20; 'extension': 0.21; 'url:home': 0.21; 'maybe': 0.21; 'dec': 0.22; '(or': 0.22; "doesn't": 0.22; 'feb': 0.22; 'received:166': 0.23; 'math': 0.24; 'structure': 0.25; "i'm": 0.27; 'separate': 0.28; 'lee': 0.28; 'second': 0.29; 'support,': 0.30; 'ctypes': 0.30; 'disabled': 0.30; 'enabled': 0.30; 'os,': 0.30; 'support)': 0.30; 'error': 0.30; 'values': 0.32; 'does': 0.32; "isn't": 0.32; 'sort': 0.32; 'to:addr:python-list': 0.33; 'checking': 0.34; 'certain': 0.34; 'curious': 0.34; 'flag': 0.34; 'leaves': 0.34; 'maintained': 0.34; 'header:X-Complaints-To:1': 0.34; 'something': 0.35; 'apply': 0.35; 'file': 0.35; 'charset:us-ascii': 0.36; 'entry': 0.37; 'but': 0.37; 'received:org': 0.37; 'cases,': 0.38; 'signal': 0.38; 'some': 0.38; 'subject:with': 0.38; 'url:org': 0.39; 'why': 0.39; 'being': 0.39; 'logs': 0.39; 'subject:: ': 0.39; 'change': 0.40; 'might': 0.40; 'to:addr:python.org': 0.40; 'worth': 0.61; 'full': 0.62; 'back': 0.62; 'afraid': 0.63; 'here': 0.64; 'expert': 0.65; 'dennis': 0.73; 'placing': 0.74; '(4,': 0.84; '-0800': 0.84; 'obvious,': 0.93
X-Injected-Via-Gmane http://gmane.org/
To python-list@python.org
From Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject Re: python reliability with EINTR handling in general modules
Date Thu, 02 Feb 2012 11:34:26 -0500
References <e88d4cff-5f45-4ccf-aa59-46ffe33adf74@w4g2000vbc.googlegroups.com> <mailman.5302.1328112606.27778.python-list@python.org> <ca89c3f0-24b4-4e8b-816b-f756e5be637e@o12g2000vbd.googlegroups.com>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
X-Gmane-NNTP-Posting-Host mobile-166-147-103-241.mycingular.net
X-Newsreader Forte Agent 6.00/32.1186
X-No-Archive YES
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.12
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.5363.1328200485.27778.python-list@python.org> (permalink)
Lines 46
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1328200485 news.xs4all.nl 6950 [2001:888:2000:d::a6]:53744
X-Complaints-To abuse@xs4all.nl
Xref x330-a1.tempe.blueboxinc.net comp.lang.python:19801

Show key headers only | View raw


On Wed, 1 Feb 2012 23:25:36 -0800 (PST), oleg korenevich
<void.of.time@gmail.com> wrote:


>Thanks for help. In first case all vars is python integers, maybe
>math.floor is redundant, but i'm afraid that same error with math
>module call will occur in other places of app, where math is needed.
>Strange thing here is that math library call is not a system call, and
>strange exception ValueError (all values have right values) and why in
>braces i have (4, Interruted system call).
>
	math.floor() may still be a system call of some sort if access to
the math processor requires synchronization between processes (that is,
the math processor/registers are maintained as a separate structure
apart from the task status during process switches). {Yes -- that is a
wild hypothesis}

	Or perhaps you haven't enabled the full math support in the runtime
-- from http://uclibc.org/FAQ.html

       >In other cases, uClibc leaves certain features (such as full C99
Math library support, wordexp, IPV6, and RPC support) disabled by
default. 

FYI: uClibc 9.33 has been released -- might be worth checking the change
logs to see if something might apply to the problems.

>For second case: if python really does some slow system call from
>module os, why it doesn't handle EINTR and not restart call. Is
>SA_RESTART flag in signal can be solution? But how i can set this
>flag? By placing flag for signal handler in c extension (or ctypes
>manipulation)?

	Note that it is identifying "firmware" as the system call (If I
understand the nature of the traceback). Is "firmware" a real file
system directory or some virtual entry that translates into scanning the
hardware/ROM for information. (If it isn't obvious, I'm not an OS
internals expert -- though I was able to get around in DEC (Open)VMS
back in the 90s).

	What has me curious is: WHAT signal is being seen that is
interrupting the system call.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

python reliability with EINTR handling in general modules oleg korenevich <void.of.time@gmail.com> - 2012-02-01 06:15 -0800
  Re: python reliability with EINTR handling in general modules Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-02-01 11:07 -0500
    Re: python reliability with EINTR handling in general modules oleg korenevich <void.of.time@gmail.com> - 2012-02-01 23:25 -0800
      Re: python reliability with EINTR handling in general modules Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-02-02 11:34 -0500
        Re: python reliability with EINTR handling in general modules Mel Wilson <mwilson@the-wire.com> - 2012-02-02 14:42 -0500

csiph-web