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