Re: thread ids, task ids and subsystems

[Marcus Brinkmann]

On Tue, Apr 08, 2003 at 09:59:40PM +0200, Niels Möller wrote:
> You're thinking about things like the protocols for transfer of port
> rights? I'd expect that every server have to implement that, except
> servers that have *only* privileged calls. Or provides its own
> protocols for transfer (like the memory server?).

It just occured to me that maybe we are sometimes not focussing the same
topics at the same time in this discussion :)

The issues as I see them are the following:

* Do we make use of the port/handle concept in the task server or not?
  I originally wanted to start off without this, because you said
  (correctly) that it is desirable to be able to use the task server in
  other, non hurdish systems, too, and because having (nr of processors)
  handles is overkill.  But when we talk about non-privileged users calling
  on the task server directly (which should be possible if we don't want to
  route everything through proc via proc ports/handles), then we need an
  "authentication" mechanism in the task server, and that would basically be
  identical to the port/handle system.  So, I concluded that yes, we do need
  the port/handle concept in the task server.  If we need it only for tasks
  or also for threads I don't know yet.  Performance isn't hurt so bad.
  I would like to ensure that rpcs for the same task are very quick (as they
  can be authenticated by comparing the senders task id in the version field
  of the thread id with the task id the rpc is sent to).  Tasks sending RPCs
  to other task ports might be a wee bit slower because you need to verify
  if that is allowed by looking it up in a hash or list of some sort.  But
  usually tasks don't keep other tasks task port, so usually that wouldn't
  be a problem.

* Accounting ids are then free to be just that, and used for accounting. 
  That means accounting the tasks resources as well as some sort of task
  relationship.  I will take a look at other systems accounting interfaces
  to see what "standards" already exist and which features are desirable.
  We can then decide how accounting ids are given out.  I imagine this:
  Usually login would set the initial user task to the accounting id of the
  user.  This can be made a bit more flexible by splitting the accounting id
  into a system part and a user part, and let users set the user part
  freely.  This way a user could implement some sort of sub-accounting
  without much work.  This would probably only be really useful if the user
  would be allowed to set resource limits for such subaccount ids.  Maybe
  subaccounts are not really useful and users should have to use proxy
  servers to achieve that.

>From this, several sub issues have spawned:

* How to get maximum thread creation/destruction performance.  Indeed, we
  need either a special case here, or we have a processor field in the
  handle which is set to the processor id.  This would mean that all Hurd
  servers must have as many receiver (dispatcher) threads as processors.
  This surely wouldn't be bad for over-all performance, right?
  Then a handle would look like this:

  [Global Server Receiver Thread ID]  [Object ID]
= [ [Subsystem ID], [Base Thread ID], [Processor ID], [Task ID] ]  [Object ID]

  Where [Base Thread ID], [Processor ID] is the Thread Number in the Global
  Thread ID scheme I posted recently.

  I think it would be easy enough to completely encapsulate this in libports
  on the server side and libhurduser on the user side.  You could even retry
  with processor ID 0 if the real processor id doesn't work if you want to
  allow simple servers with only one receiver thread.

* What should the interface of task server and proc server be like?
  That's of course a big question and I will work on that, but some things
  are already clear.  It will have similarities to the Mach interface and to
  the L4 interface, and some new interfaces for things like setting the
  accounting id are necessary, too.  Things like "proc_dostop" will move to
  there, too (where special optimizations for L4 can be applied in the
  implementation).

So much for now.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/