Status of side-effecting functions in python

[Nobody]

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.