Proof of hypothetical syllogism by constructive dilemma[edit]
/ / Lemma: Logical equivalences involving conditional statements B
/ / Lemma: Identity laws A
/ / Lemma: Negation laws A
/ / Lemma: Constructive dilemma
/ / Lemma: Logical equivalences involving conditional statements A
.1 / / premise
.11 / .1 / Logical equivalences involving conditional statements B
.12 / .11
.13 / .1 .12
.14 / .13 / Identity laws A
.15 / .14
.16 / .15
.17 / .13 .16
.18 / .17
.19 / .18 / Negation laws A
.2 / .19
.21 / .18 .2
.22 / .21 / Constructive dilemma
.23 / .22
.24 / .23
.25 / .24 / Logical equivalences involving conditional statements A
.26 / .25
.27 / .24 .26
.28 / .2 .27
.29 / .28
.3 / .16 .29
.31 / .12 .3 / conclusion
Getting rid of the daemon & speeding up D-Bus without hacking the kernel?[edit]
Someone pointed out that Dbus is very slow in an e-mail of DBus's mailing list. According to Speeding up D-Bus [LWN.net], the performance issue again has something to do with the "daemon" or "server process", just like the issue X Window is facing. The problem, as my understanding, is DBus daemon and X Server get involved too much so that frequent IPC between server and clients slows down the whole subsystems. Offloading server's job to the clients should somewhat improve the situation.
Diagram 1 demonstrates a DBus flow where Process A sends a message to Process B. (I know very little about DBus, all diagrams here are just to demonstrate the idea only) When message sent by Process A arrives Process B, it calls its message handler to handle the message. Because each message must pass through the DBus daemon, a message sent by a client process must undergo at least two context switches to be propagated to the client process on the other side.
Diagram 1
The Message handler in Diagram 1 may look like this:
void messageHandler(DBusMessage & dBusMessage)
{
if (dBusMessage == FOO_MESSAGE) {
... do something for FOO_MESSAGE ...
} else if (dBusMessage == BAR_MESSAGE) {
... do something for BAR_MESSAGE ...
} else if (dBusMessage == ...) {
...
}
}
Message Handler is executed in the context of Process B. Normally, the handler need to access variables in address space of Process B in order to do something useful.
The flow in Diagram 1 shows the possible high latency problem (made by context switches) currently DBus has. So I came up with a simple idea to change the design like this:
Diagram 2
Mechanism of shared memory is the foundation in this design. The message handler code and all variables it would access are shared by the message sender process (Process A) and the message receiver process (Process B) (as shown in Diagram 2 where address space of Process A and Process B overlap on the Message handler part). The role of DBus daemon is no longer be a message relay or router. Instead, the daemon is more like a telephone operator whose job is to bind the receiver's message handler to the sender so that when the sender wants to send a message to the receiver, it actually calls the message handler of the receiver directly. Similar to the original design, the message is passed as an argument to the message handler messageHandler(DBusMessage & dBusMessage), but the handler is now called by the message sender rather than by the message receiver, which implies the handler is executed in the context of the sender rather than executed in the context of the receiver. The outcome of the design is that the two context switches in the original design are completely eliminated (the latency is gone) and no kernel hacking is required (required by the solution mentioned in article "Speeding up D-Bus [LWN.net]" above) ... although synchronization would be needed because sender and receiver may share some part of variables.
So I would like to know how do you think about the new design? And is it feasible? Is it really beneficial? Or my description is unclear? --
how to make synchronization of receiver variable transparent to programmer is the challenge, choices may be:
page fault or SIGSEGV (enforced by mprotect()) to protect shared variables transparently
ptrace to set data breakpoint / ptrace to instrument code of client process
call mmap() with MAP_SHARED when client process calls library functions to share out its message handler (alt: ptrace to force client process to call mmap() with MAP_SHARED)
change DBus interface where programmer must use APIs with sync. to access shared varibles
suggest people stop using DBus (inadequate, unfriendly interface & undemocratic policy) and switch to other existing IPC comparable with DBus yet adquate (can do as good as my suggested new design)
so many people in need for speed, but DBus can't satisfy them and no existing candidate to use. So we should create one for ourself!
link (bind) from message sender to message receiver's event handler dynamically, sender calls receiver's handler directly instead of sending message to receiver
multicast
maintain shared memory maps? or open mmap() file descriptors? shared mem mapping still in effect after fd is closed?
Is it possible to transfer the handler code (and accessed variables) from Process B to A such that Process A may call the handler directly?
(it's undeniable (isn't it?) there are so many applications depend on such client-server design, e.g. httpd, sshd, ...)
what's the difference between KDBus & Alberto Mardegan's [1][2]?
Alberto Mardegan's won't results N^2 connections?
DBus spec. says its low-latency, misleading?
Don't be afraid to rewrite existing code, otherwise we can only achieve suboptimal. I would rather create my own IPC instead of using DBus
![{\displaystyle [(P\rightarrow Q)\land (R\rightarrow S)\land (P\lor R)]\rightarrow (Q\lor S)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/ad4b1251ab100a709417bbcff090b8f34db6d71c)
![{\displaystyle [(\neg q\rightarrow \neg p)\land (q\rightarrow r)]\land \top \leftrightarrow (\neg q\rightarrow \neg p)\land (q\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/44f0c9e0d9e8756fe070e60bee723cd012413454)
![{\displaystyle [(P\rightarrow Q)\land (R\rightarrow S)\land (P\lor R)]\rightarrow (Q\lor S)\;\left|\;{\begin{array}{l}P:q\\Q:r\\R:\neg q\\S:\neg p\end{array}}\right.}](https://wikimedia.org/api/rest_v1/media/math/render/svg/c4579ea1404ac230c904bddaa6f9e297a34362a8)
![{\displaystyle [(q\rightarrow r)\land (\neg q\rightarrow \neg p)\land (q\lor \neg q)]\rightarrow (r\lor \neg p)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/0486c8929558f05962e6ff52d7197b65fb1f2d50)
![{\displaystyle [(q\rightarrow r)\land (\neg q\rightarrow \neg p)\land (q\lor \neg q)]\rightarrow (\neg p\lor r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/40123349b2b0adf3f69b8a1dfe7809cc0bb252c7)
![{\displaystyle [(q\rightarrow r)\land (\neg q\rightarrow \neg p)\land (q\lor \neg q)]\rightarrow (p\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/5761277022739bed36af7d3876287ebe06b474cf)
![{\displaystyle [(q\rightarrow r)\land (\neg q\rightarrow \neg p)\land \top ]\rightarrow (p\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/34a57292d02f17bc725c648728f6cbe3168687c0)
![{\displaystyle [(\neg q\rightarrow \neg p)\land (q\rightarrow r)\land \top ]\rightarrow (p\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/29c40828e033bf3e4cd7711423f23c9a02f430f6)
![{\displaystyle [(\neg q\rightarrow \neg p)\land (q\rightarrow r)]\rightarrow (p\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/c2f7ab5d2621107dbdd3fb8e219ebfe1de39251e)
![{\displaystyle [(p\rightarrow q)\land (q\rightarrow r)]\rightarrow (p\rightarrow r)}](https://wikimedia.org/api/rest_v1/media/math/render/svg/935a502500361b244f9e59056f5d9839cd20d67a)
