@oleksandr-pavlyk: Would you mind to review my change?

See also #31789

I am not sure I understand how this preprocessor variable gets populated and with what value. Is the intent to expose the value of MINSIGSTKSZ from Linux headers interpreter was compiled against?

After building with ./configure && make from the branch:

bash-4.4$ git status
On branch minsigstksz
Your branch is up to date with 'vstinner/minsigstksz'.

nothing to commit, working tree clean
bash-4.4$ ./python -c "import os; print('SC_MINSIGSTKSZ' in os.sysconf_names)"
False
bash-4.4$ grep -n "SC_MINSIGSTKSZ" Modules/posixmodule.c
12349:#ifdef _SC_MINSIGSTKSZ
12350:    {"SC_MINSIGSTKSZ",   _SC_MINSIGSTKSZ},

I am not sure I understand how this preprocessor variable gets populated and with what value. Is the intent to expose the value of MINSIGSTKSZ from Linux headers interpreter was compiled against?

The intent is to provide the constant if present at compile time so that one could write os.sysconf(os.sysconf_names['SC_MINSIGSTKSZ']).

I am not sure I understand how this preprocessor variable gets populated and with what value. Is the intent to expose the value of MINSIGSTKSZ from Linux headers interpreter was compiled against?

The intent is to provide the constant if present at compile time so that one could write os.sysconf(os.sysconf_names['SC_MINSIGSTKSZ']).

Thank you for the explanation. This would be the way for Python user using pre-built distribution to infer the value of preprocessor variable MINSIGSTKSZ at the interpreter build time.

What confuses me is that the key 'SC_MINSIGSTKSZ' does not seem to be present in os.syconf_names in my local build of the branch. Perhaps the build procedure I am using, ./configure && make is not sufficient for me to see the variable in the built interpreter.

It would also be useful to expose the actual value of stack_t.ss_size that faulthandler is using.

bash-4.4$ ./python -c "import os; print('SC_MINSIGSTKSZ' in os.sysconf_names)"
False

Maybe your OS (glibc version) doesn't have the constant yet. I'm using Fedora 35 which provides glibc 2.34:

vstinner@apu$ grep -R _SC_MINSIGSTKSZ .
./bits/confname.h:    _SC_MINSIGSTKSZ,
./bits/confname.h:#define	_SC_MINSIGSTKSZ			_SC_MINSIGSTKSZ

$ rpm -qf /usr/include/bits/confname.h
glibc-headers-x86-2.34-25.fc35.noarch

The intent is to provide the constant if present at compile time so that one could write
os.sysconf(os.sysconf_names['SC_MINSIGSTKSZ']).

The intented usage is just:

>>> os.sysconf('SC_MINSIGSTKSZ')
2032

But it also works to pass directly the constant

>>> os.sysconf(os.sysconf_names['SC_MINSIGSTKSZ'])
2032

>>> key=os.sysconf_names['SC_MINSIGSTKSZ']
>>> key
249
>>> os.sysconf(key)
2032

Thanks for the review @gpshead. I merged my PR.

It would also be useful to expose the actual value of stack_t.ss_size that faulthandler is using.

I would prefer to not expose such low-level value. In Python, we try to provide high-level API like "implement a signal handler": signal.signal() function.

Outside faulthandler, I'm not aware of any stdlib module which needs to run a signal handler with its own dedicated stack.

This would be the way for Python user using pre-built distribution to infer the value of preprocessor variable MINSIGSTKSZ at the interpreter build time.

On Linux, glibc sysconf(_SC_MINSIGSTKSZ) uses GLRO(dl_minsigstacksize) which is set by AT_MINSIGSTKSZ key of the ELF Auxiliary Vectors. See the Linux documentation of the x86 Auxiliary Vectors: https://docs.kernel.org/x86/elf_auxvec.html

It doesn't seem like a hardcoded constant, but a value sent to userspace by the kernel.

Or maybe I misunderstood your commeent. Are you talking about the _SC_MINSIGSTKSZ constant?

bash-4.4$ ./python -c "import os; print('SC_MINSIGSTKSZ' in os.sysconf_names)"
False

Maybe your OS (glibc version) doesn't have the constant yet. I'm using Fedora 35 which provides glibc 2.34:

vstinner@apu$ grep -R _SC_MINSIGSTKSZ .
./bits/confname.h:    _SC_MINSIGSTKSZ,
./bits/confname.h:#define	_SC_MINSIGSTKSZ			_SC_MINSIGSTKSZ

$ rpm -qf /usr/include/bits/confname.h
glibc-headers-x86-2.34-25.fc35.noarch

Yes indeed, my bits/confname.h does not have that constant.

I tried reviewing it, learned something new :)

For future reference about _SC_MINSIGSTKSZ: https://sourceware.org/pipermail/libc-alpha/2021-January/121996.html