Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Such issues are answered when looking at the details.  For example, proc
> assigns PIDs to every task.

It's a little hard to sort this out when we don't know what the proc
server is like, but I guess we're now considering the model that the
proc server keeps a one-to-one mapping between tasks and pids.

Then the problem is that during the exec, we have two tasks
representing the same process. Thought experiment: If you kill -9
4711, and happen to do that at a moment when process 4711 is in the
middle of an exec, *both* tasks should be killed.

Having to allocate a new pid just to have two tasks for a short while,
doesn't seem right to me. But if we do that, does it matter exactly
when the old pid is transferred to the new task? It may be simpler to
do it early, like

  Old Task              New Task
  Create new task
  Swap pid with the new task
  ...

Just to get something a little different, consider a task server
associating accounting id:s to tasks, and voluntarily proc server
registration (i.e. there's no one-2o-one mapping between tasks and
pids).

A PID is an object handle to proc. Consider process 4711 (associated
with the accounting id 4711 in the task server) performing an exec:

  Old task              New task        Comments

  Arrange handles and other
    state to be transferred
    to the new task
  ...

| Create new task                       (the task inherits acounting id 4711)
| Setup pager
| Start task
|                       Fault in
| Grant stub page                       (besides code, the page should include
|                                        the task id of the old task)
|
| Send startup          Receive startup (transfers object handles,
|   message               message        including <proc, 4711>,
|                                        and a memory blob)
| Suicide
                        ... later, in startup code ...
                        Register with proc

                        Use the handles and memory blob from
                          the startup message to initialize libc
                          (fd:s, cwd, etc).

In the last step, registering with proc, the task already has an
object handle that gives it control over PID 4711, so it should send a
registration message saying "I want to be a POSIX process, and I
already have the PID 4711". The call could even block in proc until
all other tasks that own a object handle for PID 4711 have died.

Actually this proc registration is a little fuzzy to me. The
POSIX-process object in the proc server already exists (during the
exec, at any time it will have one or two references), and the new
task already owns a handle to it, implying that the proc server
already knows about it and has requested death notifications for it,
etc, so what is the registration about?

Note that during this exchange, a kill -9 4711 at any time will work
as expected. It sends a message to proc whch does access control, and
then proc sends a message to the task server, "terminate all tasks
with the accounting id 4711".

What I like about this exchange is that the exec handling proper (the
section marked with | above) need not know about proc, it only needs to
talk to the task server, and it needs to know the protocols for
transfer of object handles.

Regards,
/Niels