Peter Edwards <pea...@arista.com> added the comment:
On Wed, 14 Aug 2019 at 23:13, STINNER Victor <rep...@bugs.python.org> wrote: > > STINNER Victor <vstin...@redhat.com> added the comment: > > About PR 13649, I'm not sure that _PyThread_preferred_stacksize() is still > relevant, since my change fixed test_faulthandler test_register_chain(). I > chose my change since it's less invasive: it only impacts faulthandler, and > it minimalizes the memory usage (especially when faulthandler is not used). > Sure - there's no reason for it to exist if you don't want to use it to fix the issue here. > Python/thread_pthread.h refactor changes of PR 13649 are interested. Would > you like to extract them into a new PR which doesn't add > _PyThread_preferred_stacksize() but just add new PLATFORM_xxx macros? > Yes, certainly. Maybe test_faulthandler will fail tomorrow on a new platform, but I prefer > to open a discussion once such case happens, rather than guessing how > faulthandler can crash on an hypothetical platforms. Well, one argument for the dynamic approach is that existing python binaries can adjust without needing to be respun for new CPUs. I think SIGSTKSZ is a vestage from when CPU architectures had consistently sized register sets across models. Its interesting to read the comment on the IA64 definition for SIGSTKSZ: https://github.com/torvalds/linux/blob/master/arch/ia64/include/uapi/asm/signal.h#L83 > I'm sure that libc developers are well aware of the FPU state size and > update SIGSTKSZ accordingly. > The current value comes from the kernel sources, and has not changed since at the latest 2005 (with the initial git commit of the kernel), which I think predates xsave/xrestore by some margin. I don't think its a useful measure of anything in the real (x86) world today. > glibc code computing xsave_state_size: > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-features.c;h=4bab1549132fe8a4c203a70b8c7a51c1dc304049;hb=HEAD#l223 > > -- > > If tomorrow, it becomes too hard to choose a good default value for > faulthandler stack size, another workaround would be to make it > configurable, as Python lets developers choose the thread stack size: > _thread.stack_size(size). > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue21131> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21131> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
