Date: Fri, 21 Dec 2018 16:52:42 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 221700] lang/python??: subprocess does not use closefrom, calls close(2) hundreds of thousands of times Message-ID: <bug-221700-21822-1Y2MeMlBPp@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221700-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-221700-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221700 --- Comment #13 from Conrad Meyer <cem@freebsd.org> --- (In reply to Ed Maste from comment #10) @Koobs (re: twitter), why would it not be async signal safe? In general signal safety is more about interacting with userspace memory st= ate of ordinary non-signal contexts given arbitrary signal interruption. I.e., classic example is stdio FILE objects, which may be locked or have corrupt, half-modified state. closefrom(2) is just a plain system call. The original commit, r194262, just says: > Note that this implementation of closefrom(2) does not make any effort to > resolve userland races with open(2) in other threads. As such, it is not > multithread safe. That is a comment on threading, not signals. Signaled, single-threaded programs are still single-threaded; the signal context and ordinary thread context do not run concurrently. And by definition, a user process cannot run code of any kind =E2=80=94 sig= nal-handler or ordinary =E2=80=94 while that user process is in the kernel. So closefr= om(2) in signal handler cannot race with open(2) or other syscalls that create fds in single-threaded programs. The scenario the comment refers to is something like this: - The program has two threads and fds 0-5 allocated. - Concurrently, thread A and B attempt to: A: open() a new fd B: closefrom(3) - The behavior is unpredictable and depends on which thread acquires the fdesctable lock first. [r194262]: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D194262 --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221700-21822-1Y2MeMlBPp>