Change pid_t base type

[Henri Chataing]

Hello,

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 ?

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.

Thanks !

Bests regards,
Henri

[Joel Sherrill]

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?

--joel

Post by Henri Chataing
Hello,
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 ?
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.
Thanks !
Bests regards,
Henri

[Eric Blake]

Post by Joel Sherrill
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.

"The implementation shall support one or more programming environments
in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t,
and useconds_t are no greater than the width of type long. The names of
these programming environments can be obtained using the confstr()
function or the getconf utility."

Post by Joel Sherrill
Is POSIX a concern? Or is long 64-bits on all your targets?

If long is 32 bits, do you support two separate compilation environments
(one for POSIX with 32-bit pid_t, the other for full 64-bit pid_t)?

[Henri Chataing]

Hello,

sorry for the late reply, I forgot to hit the reply-all on my last mail
it seems ...
I wasn't aware of this limitation. We are working on 32 bit platforms as
well as 64 bits, so no easy way out.
I suppose we could support two compilation environments by deactivating
fork / kill / getpid if pid_t when long is 32bits.
Do you think it is possible anyway to change the library to enable
overwriting the type pid_t ?
Thanks !

Henri Chataing

Post by Eric Blake

Post by Joel Sherrill
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.

"The implementation shall support one or more programming environments
in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t,
and useconds_t are no greater than the width of type long. The names
of these programming environments can be obtained using the confstr()
function or the getconf utility."

Post by Joel Sherrill
Is POSIX a concern? Or is long 64-bits on all your targets?

If long is 32 bits, do you support two separate compilation
environments (one for POSIX with 32-bit pid_t, the other for full
64-bit pid_t)?

[Brian Inglis]

Post by Joel Sherrill

Post by Henri Chataing
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 ?
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).

[Eric Blake]

Post by Brian Inglis

Post by Joel Sherrill

Post by Henri Chataing
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.

Post by Brian Inglis

Post by Joel Sherrill

Post by Henri Chataing
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.