[lkml]   [2006]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: question: pid space semantics.
    "Ulrich Drepper" <> writes:

    > On 3/14/06, Eric W. Biederman <> wrote:
    >> The question:
    >> If we could add additional pid values in different pid spaces to a
    >> process with a syscall upon demand would that lead to an
    >> implementation everyone could use?
    > Before going into this, how do propose to solve some other issues:
    > - RT signal contexts have a si_pid field which contains the PID of the
    > sender. When and how do you fix this up? Can a process which is not
    > visible in a second PID space send a signal to a process in that
    > second PID space?
    > - similar problem: SysV IPC. How do you fix up fields like msg_lspid
    > in struct msqid_ds?
    > - the proposed futex extensions for robust and maybe PI mutexes needs
    > to store the TID in the futex field. If the futex shared by processes
    > in different PID spaces this value is worthless.

    Odd. I did not see that in Ingo's patches on the kernel list.
    Perhaps only user space cares about storing the tid in the futex

    > It would perhaps be conceivable to fix up the first two problems in
    > some cases. If the process is visible in the PID space of the
    > receiver of the signal or the process which calls msgctl() etc the
    > kernel could magically fill in the correct PID for the PID space. But
    > what to do if the process is not visible?
    > And for the futex case, the kernel is not involved in the fast path.
    > There is no magic fixup which can happen.
    > I don't see at all how any of these things can work without breaking
    > all kinds of code.

    The point of containers and their building blocks largely is isolation
    so you can have multiple different user space environments on one
    machine. So for most of the pieces that can really confuse user space
    the answer is don't do that then. The classic example is pid files
    for remembering a daemon is running.

    Interactions do need to happen between pid spaces for certain
    administrative actions, and as much as possible I don't want
    to reinvent the wheel. Pid alases in the kernel are for
    that purpose, and so will likely play a role in the RT signal
    and the sysv shm case.

    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: 2006-03-15 06:43    [W:0.021 / U:49.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site