libports is a convenience library for easier handling of Mach ports. It is documented in the Reference Manual.

libports is not (at least, not for now) a generalization / abstraction of Mach ports to the functionality the Hurd needs, that is, it is not meant to provide an interface independently of the underlying microkernel.

libports does not itself depend on libpthread, but the appropriate threading hooks are used if present, that is if libpthread is used by another component.

Message Processing

ports_manage_multithreaded

When a message is recieved, the thread acting as receiver checks if any other thread is also waiting for requests. If there is none, a new thread is spawned. Thus, the current thread continues processing the message while the newly created thread starts listening for new ones. (open issue hurd: multithreading.)

Also, there are configurable timeouts for translators who want to go away when they are not used. (open issue hurd: there used to be bugs in this area, id:"87hev152we.fsf@becket.becket.net", but it may be fixed as of id:"20111030210045.GA4983@myhost", hurd/hurd.git commit 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b.)

Open Issues

Several on the Open Issues page

IRC, freenode, #hurd, 2013-11-14

<teythoon> # portinfo $(pgrep mach-defpager) | tail -n 1
<teythoon> 16819001: receive
<teythoon> is that normal ?
<braunr> it can be, yes
<braunr> port names can be renamed
<braunr> there are a few occurrences in the code
<braunr> see
  http://www.gnu.org/software/hurd/gnumach-doc/Port-Names.html#Port-Names
<teythoon> I know
<braunr> mach-defpager/default_pager.c:  kr = mach_port_rename(
  default_pager_self,
<teythoon> heh, it is a pointer
<teythoon> I thought that'd make stuff inefficient in gnumach?
<braunr> it does
<braunr> such rights are moved from a regular fast-access table to a splay
  tree
<braunr> but when i looked into it, there were never more than a few dozen
  rights in these trees
<braunr> (which is why i didn't merge my radix tree in gnumach)
<teythoon> I've been contemplating to replace the libihash usage in
  libports with a simple array
<braunr> consider a radix tree too then :)
<teythoon> well, I did
<braunr> ok
<teythoon> but I'm not convinced that it would do better than a simple
  array (or the current ihash implementation)
<braunr> really ?
<teythoon> what do you hope to gain?
<braunr> i'm practically certain it would do better than the current ihash
  code
<braunr> uh, speed
<braunr> the problem with an array or a hash table is resizing
<braunr> a well tuned radix tree (say 64 ot 512 items per node) can reduce
  to a simple array for the common case
<teythoon> right
<teythoon> but consider the use case
<braunr> and scale very well for massive users such as file systems which
  can reach several hundred thousand rights
<teythoon> hm
<braunr> an array could be very efficient as well
<braunr> i'm just concerned about resizing
<teythoon> but this is a problem with the current implementation as well
<braunr> sure
<braunr> we're not considering keeping it anyway
<braunr> this discussion is about array vs radix tree
<braunr> the radix tree also has the advantage to efficiently deal with
  sparsely populated port name spaces
<braunr> to some degree
<braunr> which is probably what you're currently concerned with about this
  weird port name in defpager :)
<teythoon> http://paste.debian.net/65780/
<teythoon> yes, but mach-defpager does not use libports
<braunr> ok

See also discussion on deficiencies, X15, IRC, freenode, #hurd, 2013-11-14.