[lkml]   [2002]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Linux-2.5 fix/improve get_pid()
    On Thu, Aug 08, 2002 at 02:24:19AM +0200, Andries Brouwer wrote:
    > Here it is of interest how large a pid is.
    > With a 64-bit pid_t it is just
    > static pid_t last_pid;
    > pid_t get_next_pid() {
    > return ++last_pid;
    > }
    > since 2^64 is a really large number.
    > Unfortunately glibc does not support this (on x86).
    > With a 32-bit pid_t wraparounds will occur, but very infrequently.
    > Thus, finding the next pid will be very fast on average, much faster
    > than the above algorithm, and no arrays are required.
    > One only loses the guaranteed constant time property.
    > Unless hard real time is required, this sounds like the best version.

    The goal of the work that produced this was to remove the global
    tasklist. Changing ABI's and/or breaking userspace was not "within the
    rules" of that. My allocator relies on that other infrastructure for
    notification of release of pid's, and is really only meant to remove
    the reliance of fork() on the tasklist. That work is probably more
    relevant to heavy tty usage than forkbombs, despite the O(1) get_pid().
    I am glad people happen to like various tidbits of it, though. =)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.023 / U:20.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site