-
Notifications
You must be signed in to change notification settings - Fork 0
/
00244.mbox
115 lines (110 loc) · 5.53 KB
/
00244.mbox
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
103
104
105
106
107
108
109
110
111
112
113
114
115
From [email protected] Tue Jul 16 12:17:23 2002
Received: from ppp-117-61.26-151.libero.it ([151.26.61.117] helo=localhost.localdomain)
by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian))
id 17UV0s-0003Pu-00
for <[email protected]>; Tue, 16 Jul 2002 12:17:23 -0400
Received: from rreale by localhost.localdomain with local (Exim 3.12 #1 (Debian))
id 17UV17-0000aw-00
for <[email protected]>; Tue, 16 Jul 2002 18:17:37 +0200
Date: Tue, 16 Jul 2002 18:17:37 +0200
Subject: Re: Message passing in user-land
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: [email protected]
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>,
<mailto:[email protected]?subject=subscribe>
List-Id: Bug reports for the GNU Hurd <bug-hurd.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/bug-hurd/>
On Tue, Jul 16, 2002 at 04:09:16PM +0200, Niels M?ller wrote:
> [email protected] writes:
>
> > But how much performance imprevement would we achieve if we created such
> > a mechanism, only for pure data?
>
> The fastest way to do it that I can imagine, for the simplest case of
> mutually trusting processes, is to have a (possibly) short message
> queue, protected by a mutex and some condition variables, all in th
> eshared memory page. It's not obvious to me if that will be slower or
> faster than L4 ipc that can pass the data in registers.
>
> Furthermore, I have never implemented mutexes and condition variables,
> but I wouldn't be surprised if some syscall is needed for conditions
> to propagate between threads or processes.
>
> Regards,
> /Niels
I'll try to roughly explain my idea, which doesn't apply
to every IPC type, but only to a small subset thereof. This
subset includes the message passing between a client/server
pair and among the servers themselves, with the additional
constraint of very small pieces of data being passed at once.
In this scenario we could use one (or even more) system-wide
data structure, such as a queue, to manage all the messages.
This queue would be made up of several smaller queues, each
one pertaining to a single process (or group of processes)
and used by this process to talk with one or more servers.
Each small queue would live in one page (or more, but few, pages)
or memory shared with the servers. One possible (simplified)
arrangement of the memory would look like this:
process #1 process #2 process #3
| address | | address | | address |
| space | | space | | space |
|-----------| |-----------| |-----------|
| text etc. | | text etc. | | text etc. |
| | | | | |
|-----------| |-----------| |-----------|
| heap | | heap | | heap |
| | | | | |
|-----------| |-----------| |-----------|
| | | | | |
|-----------| |-----------| |-----------|
| IPC queue |-+ | IPC queue |-+ | IPC queue |-+
|-----------| | |-----------| | |-----------| |
| | | | | | | | |
|-----------| | |-----------| | |-----------| |
| stack | | | stack | | | stack | |
|-----------| | |-----------| | |-----------| |
| | | | | | | | |
| | |
| | |
| | |
+-----------+ | +-----------+
| | |
| | |
---------+--------+-----+----+-----+-----+-----+----+---------+--
server #1| | h |q |q |q |q | | |
address | text | e |u |u |u |u | | stack |
space | etc. | a |e 1 |e 2 |e 3 |e n | | |
| | p |u |u |u |u | | |
| | |e |e |e |e | | |
---------+--------+-----+----+-----+-----+-----+----+---------+--
| | |
| | |
| | |
---------+--------+-----+----+-----+-----+-----+----+---------+--
server #2| | h |q |q |q |q | | |
address | text | e |u |u |u |u | | stack |
space | etc. | a |e 1 |e 2 |e 3 |e n | | |
| | p |u |u |u |u | | |
| | |e |e |e |e | | |
---------+--------+-----+----+-----+-----+-----+----+---------+--
Sorry for the lack of clearness, but my idea - and for that matter
my English - are alas at early alpha stage. I'd like, however,
to hear your criticism and hopefully your suggestions.
Thanks,
Roberto