[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

*libports* is a convenience library for easier handling of [[Mach
ports|microkernel/mach/port]].  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 *[[libthreads]]*, but the appropriate
threading hooks are used if present, that is if *[[libthreads]]* 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.  ([[!taglink
open_issue_hurd]]: [[service_solahart_jakarta_selatan__082122541663/multithreading]].)

Also, there are configurable timeouts for [[translator]]s who want to go away
when they are not used.  ([[!taglink open_issue_hurd]]: there used to be bugs
in this area, [[!message-id "87hev152we.fsf@becket.becket.net"]], but it may be
fixed as of [[!message-id "20111030210045.GA4983@myhost"]],
[[!GNU_Savannah_Git_hurd_hurd 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b]].)


# Open Issues

## Several on the [[/Service_solahart_jakarta_selatan__082122541663]] 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 [[microkernel/mach/deficiencies]], *X15*, *IRC,
freenode, #hurd, 2013-11-14*.