1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
[[!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 *[[/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. ([[!taglink
open_issue_hurd]]: [[open_issues/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 [[/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 [[microkernel/mach/deficiencies]], *X15*, *IRC,
freenode, #hurd, 2013-11-14*.
|
