fork/exec & close file descriptors

Steven D'Aprano steve at pearwood.info
Wed Jun 3 08:07:47 EDT 2015


On Wed, 3 Jun 2015 07:38 pm, alister wrote:

> On Wed, 03 Jun 2015 10:41:44 +0300, Marko Rauhamaa wrote:
[...]
>> Here's the deal: the child process is saddled with file descriptors it
>> never wanted in the first place. It can't decline them. Now you're
>> saying it can't even dispose of them.
>> 
> No You cab dispose of them you just need to warn the user that the action
> did not complete correctly & there may be errors with the data.

*What* action? Pay closer attention to what Marko wrote:

"the child process ..."

How does the child process know what action didn't complete? What error
message are you going to display to the user?

"Error when closing file descriptor 123456"

What action do you think the user can take on seeing this error message?

 
> Example What does your test editor do if you try to save a file back to a
> USB stick that has been removed? does it simply let you think the file
> has been successfully saved? i hope not.


Correct me if I'm wrong, but don't you get an error when you try to *open* a
file on a missing USB stick?

There are at least three opportunities to get an error when writing a file:

* opening the file;
* writing to the file;
* closing the file.

It's not clear what conditions will lead to the first two succeeding but the
third failing, or what to do if you get such an error. If you don't know
what caused close() to fail, then you can't do anything about it, and if
you can't do anything about it, what's the point in reporting the error to
the user who will just get frustrated and nervous and not be able to do
anything about it either?

I'm sure that there are circumstances where an error when closing a file is
a clear and obvious fault that should be reported. But in the scenario that
Marko is describing, I'm not so sure that is the case.



-- 
Steven




More information about the Python-list mailing list