Freeing Port Rights

IRC, freenode, #hurd, 2013-07-01

<teythoon> do I have to explicitly free ports in a short lived process like
  mount?
<pinotree> better take the habit of doing that anyway
<teythoon> how do I recognize that I have to free something? mig spec?
<braunr> i'd say no
<braunr> mig does it for you
<braunr> gnumach reference manual
<teythoon> not memory, like port rights
<braunr> but no, really, for short lived processes it's ok
<braunr> yes, port rights
<braunr> like memory, you don't free stuff in short lived processes :p
<braunr> mach does it correctly when the task is destroyed
<braunr> but there are two use cases for rights
<braunr> those you create manually
<braunr> and those mig creates for its own purpose
<braunr> ignore those used by mig, they matter only in very specific parts
  of glibc and other very low level stuff
<braunr> teythoon: keep in mind that there are two flavours of resources
  with port rights
<teythoon> but how do I *know* from looking at say fs.defs that I have to
  free anything I get?
<braunr> rights themselves, and the user reference count per right
<braunr> eh, that's complicated
<braunr> in a complete RPC call, you must watch two things usually
<braunr> out of line memory
<braunr> and right references
<braunr> except otherwise mentioned, you don't have to free anything
<braunr> freeing passed memory should be obvious (e.g. "out" keyword on a
  memory range)
<braunr> for right references, it's less obvious
<braunr> refer to the mach server writing guide i guess
<teythoon> what does the dealloc qualifier do in mig defs?
<braunr> basically, send rights can be created from a receive right
  (make_send), or another send right (copy_send)
<braunr> it tells mig which function to call once an RPC has returned
<braunr> all this is described in the mach server writing guide
<braunr> and it's tricky
<braunr> quite error-prone so check with portinfo