On Fri, 14 Mar 2008, Dag Wieers wrote:
On Wed, 9 Jan 2008, Marc Lehmann wrote:
The reason for the interrupted system call as likely heavy swapping: when
the machine gets unrepsonsive for a few seconds (10+), then this happens.
An easy way to reproduce this is to press ctrl-s and wait 5-6 seconds,
then ctrl-q:
# dstat
----total-cpu-usage---- --dsk/sda-----dsk/dm-0----dsk/dm-1----dsk/dm-2-
-net/total- ---paging-- ---system--
usr sys idl wai hiq siq|_read _writ:_read _writ:_read _writ:_read
_writ|_recv _send|__in_ _out_|_int_ _csw_
89 1 8 2 0 0| 262k 37k: 398k 149k: 104B 9.5B:2684k 4864B|
0 0 | 0 0 | 443 531
100 0 0 0 0 0| 0 0 : 0 0 : 0 0 : 0 0 |
412B 226B| 0 0 | 378 90 File "/usr/bin/dstat", line 1912, in ?
print 'IOError: %s' % e
IOError: [Errno 4] Interrupted system call
Right, the problem is that I have to disable buffered writes to stdout
because I am updating the screen. And of course if it cannot directly write
to stdout (because the terminal is suspended) it interrupts the syscall.
If somehow dstat could be triggered when that happens, we could enable
buffering again. But I doubt that is a very good solution. Maybe it would
make more sense to flush the buffer at regular intervals instead of making
the output unbuffered. But I am not sure whether that could cause the same
problem, at least we then can check for xoff the moment we want to flush.
How would any other program handle this ? How would a real programmer handle
it ? :-)
I quickly did a test with buffering enabled and doing a flush. And it is
able to withstand a terminal suspend longer (until the buffer gets full).
And then again an Interrupted system call. I am wondering whether we can
increase the standard buffer, if that is wise to do and if this is the
right approach.
Anyone ? :)
--
-- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
