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

Groups > comp.lang.python > #19715

Re: python reliability with EINTR handling in general modules

Show all headers | View raw

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

>I have linux board on samsung SoC s3c6410 (ARM11). I build rootfs with
>buildroot: Python 2.7.1, uClibc-0.9.31. Linux kernel: Linux buildroot
>2.6.28.6 #177 Mon Oct 3 12:50:57 EEST 2011 armv6l GNU/Linux
>
>My app, written on python, in some mysterios conditons raise this
>exceptions:
>
>1) exception:
>
> File "./dfbUtils.py", line 3209, in setItemData
>ValueError: (4, 'Interrupted system call')
>code:
>
>currentPage=int(math.floor(float(rowId)/
>self.pageSize))==self.selectedPage
>2) exception:
>
>File "./terminalGlobals.py", line 943, in getFirmawareName
>OSError: [Errno 4] Interrupted system call: 'firmware'
>code:
>
>for fileName in os.listdir('firmware'):
>Some info about app: it have 3-7 threads, listen serial ports via
>'serial' module, use gui implemented via c extension that wrap
>directfb, i can't reproduce this exceptions, they are not predictable.
>
>I googled for EINTR exceptions in python, but only found that EINTR
>can occur only on slow system calls and python's modules socket,
>subprocess and another one is already process EINTR. So what happens
>in my app? Why simple call of math function can interrupt program at
>any time, it's not reliable at all. I have only suggestions: ulibc
>bug, kernel/hw handling bug. But this suggestions don't show me
>solution.

	I see nothing in your traceback that indicates that the interrupt
occurred in the math library call -- unless you deleted that line. In
the first one, I'd be more likely to suspect your C extension/wrapper...
(are the fields .pageSize and .selectedPage coming from an object
implemented in C?)

	As for the math stuff... I presume both rowID and .pageSize are
constrained to be 0 or positive integers. If that is the case, invoking
math.floor() is just redundant overhead as the documented behavior of
int() is to truncate towards 0, which for a positive value, is the same
as floor()

>>> neg = -3.141592654
>>> pos = 3.141592654
>>> int(neg)
-3
>>> math.floor(neg)
-4.0
>>> int(pos)
3
>>> math.floor(pos)
3.0
>>> 

	In the second case... Well, os.listdir() is most likely translated
into some operating system call.

http://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html

And, while that call is waiting for I/O to complete, some sort of signal
is being received.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next — Previous 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