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 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. (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:"[email protected]"
, 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.