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

Groups > comp.lang.python > #79819

Re: Status of side-effecting functions in python

Show all headers | View raw

On Mon, 27 Oct 2014 17:14:58 +0200, Marko Rauhamaa wrote:

> In POSIX, a write(2) system call on file blocks until all bytes have been
> passed on to the file system. The only exception (no pun intended) I know
> is the reception of a signal.

Writing to a file (or block device) will return a short count in the event
that it results in the size of the file exceeding

* the space available on the partition,
* the user's quota,
* the process' file size limit (RLIMIT_FSIZE), or
* any implementation limit on the maximum size of a file,

and at least one byte can be written. This behaviour is mandated by POSIX.

This is different to writing to a socket, pipe or character device,
where a short count is considered an entirely normal result, and
a subsequent write for the remaining bytes will often succeed.

> Even then, I'm not sure Linux file systems ever cut writes short because
> of signals.

Linux never interrupts I/O on discs or block devices due to signals.
These are restarted regardless of whether the signal is set for
automatic restarting (SA_RESTART flag).

> I think the lack of nonblocking file access in Linux is one of the OS's
> main shortcomings. 

It doesn't really matter. In the absence of an explicit mlock() or
mlockall(), the actual code which would be controlling the access is
demand-paged from disc, as is the "memory" to/from which the data is
transferred (along with the memory which would hold the return code from
read() or write(), for that matter).

Asynchronous I/O in the sense of select(), poll(), O_NONBLOCK etc is meant
for situations where delays could be indefinite, e.g. network connections
or terminals. For "short" delays (i.e. disc access), there's not much
point having a mechanism so that you can avoid blocking while the data is
read from disc just so that you can block while the code in the "else"
branch is read from disc.

If you want the program to be able to do something else while waiting for
I/O, use threads. The introduction of threads made most concurrency-
related issues in the POSIX API moot.

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

Thread

Status of side-effecting functions in python Rustom Mody <rustompmody@gmail.com> - 2014-10-25 10:27 -0700
  Re: Status of side-effecting functions in python Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-10-25 23:41 +0200
    Re: Status of side-effecting functions in python Dan Sommers <dan@tombstonezero.net> - 2014-10-25 22:22 +0000
      Re: Status of side-effecting functions in python Terry Reedy <tjreedy@udel.edu> - 2014-10-25 18:53 -0400
    Re: Status of side-effecting functions in python wxjmfauth@gmail.com - 2014-10-26 00:45 -0700
      Re: Status of side-effecting functions in python Dan Sommers <dan@tombstonezero.net> - 2014-10-26 13:41 +0000
        Re: Status of side-effecting functions in python Rustom Mody <rustompmody@gmail.com> - 2014-10-26 07:53 -0700
        Re: Status of side-effecting functions in python wxjmfauth@gmail.com - 2014-10-26 09:26 -0700
          Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-26 18:50 +0200
          Re: Status of side-effecting functions in python Roy Smith <roy@panix.com> - 2014-10-26 17:56 -0400
            Re: Status of side-effecting functions in python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-27 22:30 +1100
              Re: Status of side-effecting functions in python Chris Angelico <rosuav@gmail.com> - 2014-10-27 22:44 +1100
              Re: Status of side-effecting functions in python Roy Smith <roy@panix.com> - 2014-10-27 09:28 -0400
              Re: Status of side-effecting functions in python Grant Edwards <invalid@invalid.invalid> - 2014-10-27 14:45 +0000
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-27 17:14 +0200
                Re: Status of side-effecting functions in python Nobody <nobody@nowhere.invalid> - 2014-10-28 03:52 +0000
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-28 11:07 +0200
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-28 11:10 +0200
                .write() behavior Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-10-29 01:06 -0400
                Re: .write() behavior Marko Rauhamaa <marko@pacujo.net> - 2014-10-29 08:00 +0200
                Re: .write() behavior Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-10-31 16:32 -0400
    Re: Status of side-effecting functions in python Grant Edwards <invalid@invalid.invalid> - 2014-10-27 14:22 +0000

csiph-web