pid_t data type

Casper H.S. Dik wrote:
> "jason.cipriani@gmail.com" <jason.cipriani@gmail.com> writes:
> 
> 
>
> It needs to be a signed airthmetic type:
>
>      If pid is negative but not (pid_t)-1, sig will  be  sent  to
>      all  processes  whose process group ID is equal to the abso-
>      lute value of pid and for which the process  has  permission
>      to send a signal.
>
> Since it needs to be used in comparisons it can't really be float...

Why not?  Can't the system restrict itself to the set of floating
point values that can be exactly represented with no loss of
precision (or overflow or whatever)?  :-)  Unless there's a
requirement I don't know of that a pid_t can be added or subtracted
or multiplied or something.  It seems like the platform can choose
the type of pid_t, so if the platform can know what a floating point
type can exactly represent, it could use a floating point type
for pid_t.

Getting back to the semi-practical realm, I could actually imagine a
system where a pid_t is some sort of huge integral type, where
the pid_t is a cryptographically-secure uuid or guid.  It'd make
it hard to do attacks where you guess the pid of something.  And
it'd also eliminate a lot of worries about stale pid files.  (One
less sanity check necessary before you do that "kill" to make sure
the old instance is dead.)

- Logan

Logan Shaw <lshaw-usenet@austin.rr.com> writes:

>Getting back to the semi-practical realm, I could actually imagine a
>system where a pid_t is some sort of huge integral type, where
>the pid_t is a cryptographically-secure uuid or guid.  It'd make
>it hard to do attacks where you guess the pid of something.  And
>it'd also eliminate a lot of worries about stale pid files.  (One
>less sanity check necessary before you do that "kill" to make sure
>the old instance is dead.)

VMS, for instance, used the lower 16-bits as a 'slot' number and
the upper 16-bits as a generation number, specifically to avoid
this issue.

scott

On 2008-03-19, William Ahern <william@wilbur.25thandClement.com> wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote: 
><snip> 
>
> Neo?
>

Are you sure you want to take the red pill?

--

"jason.cipriani@gmail.com" <jason.cipriani@gmail.com> writes:
> On Mar 18, 3:02 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: 
>
> I see. It also says:
>
> "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."
>
> If you take that to mean that *all* supported "programming
> environments" have pid_t with width no greater than the width of type
> long, then it *is* save to store pid_t's in a long. Is there something
> that indicates that it's not?

If a process id can be stored in an object of some particular integer
type does not depend on the type used to represent process ids by the
implementation but on the value of the process id. The maximum value
of the pid_t type limits the maximum possible value of a process id,
but this only means that the maximum actual value of it must be less
than or equal to the maximum representable value. The exact
particulars are presumably (AFAIK, SUS only demands that pid_t shall be a
signed integer type and that an actual process ID shall be positive)
implementation dependent.

Because a programming environment where a long is sufficient to hold
any possible value of a pid_t is supposed to exist, the conjecture
that 'usual implementations' will not use type larger than this
because of the additional implementation complexities associated with
doing so appears (to me) to be a reasonable one.

> If that's the case the only two issues with using long instead of
> pid_t are:
>
> 1) If that standard changes some day, and

In the future, something which is yet unknown will happen. Because it
is not known yet, it can only be dealt with in future.

> 2) Using pid_t clearly indicates that the variable, function
> parameter, etc., is meant to hold a process ID, and not some arbitrary
> integer with another meaning. Saves on documentation.

Assuming that usage of a particular variable is not evident because
the context of its usage, a name documenting its purpose would be more
useful in this respect than a lone declaration somewhere in a file.

> It seems pretty simple, what is the argument about? If you are
> prepared to face the consequences of 1 and 2 then you'd use longs, and
> if you don't want to think about it then you'd use pid_t's. I think #2
> is a big reason to use pid_t's. I also can't think of a compelling
> reason to do it otherwise.

Assume there is a subroutine calling multiple, different "UNIX(*)
calls", each returning either -1 to signal an error or some other
'useful value'. Because these usually return ints, a single int
variable with some suitable name can be used to store a 'return code',
copying actually useful 'useful values' somewhere else as desired. If
one of the calls was fork, a different return code variable or a
different way of handling return codes would be necessary just for
this single call. This means additional complications in the source
code for no 'real' benefit. Additionally, there are even situations
where the process id itself is of absolutely no interest, only if the
fork[*] succeeded. I have already (and would again) just used int in
such situations.

OTOH, I would always use pid_t for variables whose actual purpose is
to store process ids, because that's (as you have already written),
the easiest and most straight-forward option.


[*] I hereby humbly suggest that people fascinated by the idea
to 'spawn' new programs should just use and program for
operating systems more congenial to their
mentality. Especially, this would include everyone boneheaded
enough to assume that something which worked on computers
noone would use in a coffe maker nowadays needs to be changed
for "performance reasons" on present-day hardware. Present-day
software could well need a lot of changes for 'performance
reason', though. ...

Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Casper H.S. Dik wrote: 
>
> Why not?  Can't the system restrict itself to the set of floating
> point values that can be exactly represented with no loss of
> precision (or overflow or whatever)?  :-)  Unless there's a
> requirement I don't know of that a pid_t can be added or subtracted
> or multiplied or something.

Various data structures used for searching for keys (eg hash tables or
digital search tries) make use of their numerical properties.

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>Logan Shaw <lshaw-usenet@austin.rr.com> writes: 
>
>Various data structures used for searching for keys (eg hash tables or
>digital search tries) make use of their numerical properties.

1) such data structures are usuall kernel-resident and algorithms to
manipulate them reflect the choice of pid_t content.

2) Most searching is searching for bitwise equality (pid_t [!=]= pid_t).

3) Applications that assume a numeric relationship between pid_t values
are broken.

scott

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes: 

[abstract process id type]
 
>
> 1) such data structures are usuall kernel-resident and algorithms to
>    manipulate them reflect the choice of pid_t content.

Data structures intended to efficiently provide 'associative arrays'
(for specific key-set/ value-set pairs) are certainly not 'usually
kernel-resident'. I assume that you meant to write that 'process
management' (using such data structures to map process ids to some
per-process information structure(s)) is 'usually [only] done by the
kernel'. The simple counterexample for that would be a server using
pre-forked processes to serve multiple clients concurrently. One I
happen to have written is used to provide (HIPAA) 'secure download of
files containing data to print' to appliances 'on the internet' (the
more well-known example would be apache 1 ;-): A supervisor process
keeps track of which of its children are presently busy serving
download requests or idle, forking new children or killing idle
children based on some thresholds for 'MaxSpareServers' and
'MinSpareServers' and logs 'accounting records' tracking what is/ was
going on at some time.

> 2) Most searching is searching for bitwise equality (pid_t [!=]=
> pid_t).

I was specifically referring to two search data structures whose
associated algorithms perform calculations with keys (to determine a
hash value or to extract certain bits for a digital search).

> 3) Applications that assume a numeric relationship between pid_t values
>    are broken.

pid_t is required to be a signed integer type. This means that process
ID values must be integral numbers. Numbers have 'numeric
relationships' with 'other numbers', no matter what other meanings may
be associated with them in certain contexts. One property numbers,
being entirely abstract entities, don't have is 'a colour': There is
no such thing as 'a black zero' which would be different from 'a red
zero', the latter having something specific in common with 'a red one'
but not with 'a yellow five'. 'Colour' can here server as a substitute
for 'arbitrary set of disjoint attributes associated with
numbers'. Some people, eg then inventors of Ada, consider this to be
an error (eg an algorithm determining twice the number of some number
of cars should not 'just work' to determine twice the number of some
number of submarines, too). If those 'some people' had come up with
this original idea in elementary school, the net-effect would have
been a bad grade instead.

Which leads to the conclusion that 'teaching basic math' to pupils
inherently leads to 'great security risks' and presumably should be
avoided to eliminate really horrendous "error classes" :->.