This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Change pid_t base type
On 08/01/2018 03:06 PM, Brian Inglis wrote:
On 2018-08-01 08:22, Joel Sherrill wrote:
On Wed, Aug 1, 2018, 9:04 AM Henri Chataing wrote:
I am currently porting newlib to our platform provencore, which uses
64bit wide process identifiers. Everything went well except for that
last point, as pid_t seems to be hardcoded as int.
I feel that it should be possible to modify the type pid_t to use any
arbitrary signed integer.
Can you tell me if there is a reason for not allowing larger pids ?
As a matter of portable code, for a while, mingw made the mistake of
declaring a 64-bit pid_t but having 'int getpid()', which led to all
sorts of messes. I think they have since fixed it to 32-bit pid_t and
'pid_t getpid()' as a result of the bug reports raised against their
headers.
At any rate, it becomes very hard to portably printf() a pid_t value if
you cannot guarantee that printf("%ld", (long)pid) works out of the box.
The attachement contains some modifications I performed in order to be
able to override __pid_t in sys/_types.h.
The patch applies on top of
master:ab640f4cd5605b6675538b196641c46c36c75c64 in the newlib-cygwin
github mirror.
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html
Says pid_t can be no larger than long if I am reading that correctly.
Is POSIX a concern? Or is long 64-bits on all your targets?
Your platform can use 64 bit process identifiers, but those need not, and
probably should not, be exposed to userspace, but kept private in the process or
task struct. Use hashes of those as pids within system defined limits except for
pids 0 (idle) and 1 (init).
Indeed. Is your 32-bit platform really capable of running more than 2
billion simultaneous processes even when bounded by a 4G address space?
Okay, maybe you have some hardware tricks for a single process accessing
more than 4G of physical memory, but how much more? Conversely, there's
the argument that any process, even the most trivial of them, will
occupy enough space (figure at least 1k per process just for information
related to tracking the process across task swaps), that you can
reasonable assure that your hardware limitations will kick in long
before you can exhaust 32-bit pid_t in use at the same time (pid_t
wraparound is more likely when one process starts reusing the same id as
an earlier completed process, particularly when using 16-bit pids, but
portable programs have learned to be robust to pid reuse). A 64-bit
platform might actually be able to have more than 2 billion parallel
processes, but there, sizeof(pid_t) <= sizeof(long) is still reasonable
when you have 64-bit long.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org