Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #91997
| Path | csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Marko Rauhamaa <marko@pacujo.net> |
| Newsgroups | comp.lang.python |
| Subject | Re: fork/exec & close file descriptors |
| Date | Thu, 04 Jun 2015 00:09:15 +0300 |
| Organization | A noiseless patient Spider |
| Lines | 91 |
| Message-ID | <87vbf433es.fsf@elektro.pacujo.net> (permalink) |
| References | <CANc-5UyeaWqThGFSAuGskz+S2Lrgq0ia9W9DHAie28t9GY+sww@mail.gmail.com> <mailman.59.1433253538.13271.python-list@python.org> <87pp5eksnc.fsf@universite-de-strasbourg.fr.invalid> <87eglt7u5i.fsf@elektro.pacujo.net> <87lhg1lt00.fsf@universite-de-strasbourg.fr.invalid> <87a8wh7nq6.fsf@elektro.pacujo.net> <87d21dl0jc.fsf@universite-de-strasbourg.fr.invalid> <877frl6xxj.fsf@elektro.pacujo.net> <mkmhus$1sr$1@speranza.aioe.org> <556eee15$0$12975$c3e8da3$5496439d@news.astraweb.com> <878uc1567j.fsf@elektro.pacujo.net> <mailman.104.1433336055.13271.python-list@python.org> <87wpzl3pnn.fsf@elektro.pacujo.net> <87oakw532a.fsf@elektro.pacujo.net> <87iob44zu9.fsf@elektro.pacujo.net> <mailman.125.1433362139.13271.python-list@python.org> |
| Mime-Version | 1.0 |
| Content-Type | text/plain |
| Injection-Info | mx02.eternal-september.org; posting-host="b7cb1518d23ec19d482dcc9c31d30fdd"; logging-data="9296"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190eWE7q31DM2zI0bgQ4IGh" |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
| Cancel-Lock | sha1:VRgOj5NB1aqJ/xhzZpnaCDqiir0= sha1:hh2f9S2qh2KvaAGswUU5qsPN09o= |
| Xref | csiph.com comp.lang.python:91997 |
Show key headers only | View raw
random832@fastmail.us:
> On Wed, Jun 3, 2015, at 10:43, Marko Rauhamaa wrote:
>> However, the child process needs to be prepared for os.close() to
>> block indefinitely because of an NFS problem or because SO_LINGER has
>> been specified by the parent, for example. Setting the close-on-exec
>> flag doesn't help there.
>
> Out of curiosity, does exec block in this situation?
I didn't try it, but it is apparent in the source code:
========================================================================
void do_close_on_exec(struct files_struct *files)
{
unsigned i;
struct fdtable *fdt;
/* exec unshares first */
spin_lock(&files->file_lock);
for (i = 0; ; i++) {
unsigned long set;
unsigned fd = i * BITS_PER_LONG;
fdt = files_fdtable(files);
if (fd >= fdt->max_fds)
break;
set = fdt->close_on_exec[i];
if (!set)
continue;
fdt->close_on_exec[i] = 0;
for ( ; set ; fd++, set >>= 1) {
struct file *file;
if (!(set & 1))
continue;
file = fdt->fd[fd];
if (!file)
continue;
rcu_assign_pointer(fdt->fd[fd], NULL);
__put_unused_fd(files, fd);
spin_unlock(&files->file_lock);
filp_close(file, files);
cond_resched();
spin_lock(&files->file_lock);
}
}
spin_unlock(&files->file_lock);
}
int filp_close(struct file *filp, fl_owner_t id)
{
int retval = 0;
if (!file_count(filp)) {
printk(KERN_ERR "VFS: Close: file count is 0\n");
return 0;
}
if (filp->f_op->flush)
retval = filp->f_op->flush(filp, id);
if (likely(!(filp->f_mode & FMODE_PATH))) {
dnotify_flush(filp, id);
locks_remove_posix(filp, id);
}
fput(filp);
return retval;
}
========================================================================
Now, the kernel NFS code specifies a flush() method, which can block and
even fail.
Sockets don't have a flush() method. So closing a socket cannot fail.
However, fput(), which decrements the reference count, may block if
lingering has been specified for the socket.
So I wasn't all that wrong earlier after all: whoever closes a socket
last will linger. Thus, the parent (who wanted to linger) might zip
through closing a socket while the unwitting child process will suffer
the lingering delay before it gets to exec.
However, there's this comment in inet_release():
/* [...]
* If the close is due to the process exiting, we never
* linger..
*/
Marko
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 08:58 -0500
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 18:28 +0300
Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 10:42 -0500
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 19:24 +0300
Re: fork/exec & close file descriptors Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-02 16:37 +0000
Re: fork/exec & close file descriptors MrJean1 <MrJean1@gmail.com> - 2015-06-12 13:43 -0700
Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-02 17:59 +0200
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 23:05 +0300
Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-02 23:06 +0200
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 01:24 +0300
Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 09:21 +0200
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 10:41 +0300
Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 09:38 +0000
Re: fork/exec & close file descriptors Steven D'Aprano <steve@pearwood.info> - 2015-06-03 22:07 +1000
Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 12:18 +0000
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 15:27 +0300
Re: fork/exec & close file descriptors alister <alister.nospam.ware@ntlworld.com> - 2015-06-03 13:05 +0000
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 17:49 +0300
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 15:25 +0300
Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 08:54 -0400
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 16:08 +0300
Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 09:21 -0400
Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-03 23:32 +1000
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 16:33 +0300
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 17:43 +0300
Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 16:08 -0400
Re: fork/exec & close file descriptors Marko Rauhamaa <marko@pacujo.net> - 2015-06-04 00:09 +0300
Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 16:07 -0400
Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-04 07:54 +1000
Re: fork/exec & close file descriptors Chris Angelico <rosuav@gmail.com> - 2015-06-03 09:54 +1000
Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 09:11 +0200
Re: fork/exec & close file descriptors random832@fastmail.us - 2015-06-03 08:21 -0400
Re: fork/exec & close file descriptors Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-03 15:16 +0200
Re: fork/exec & close file descriptors Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-02 20:21 -0500
csiph-web