https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221700
--- Comment #13 from Conrad Meyer <c...@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 state 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 — signal-handler or ordinary — while that user process is in the kernel. So closefrom(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=revision&revision=194262 -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
