| commit | 0f03f24b5eae329c31d70da7852b400ebea48f6e | |
| author | Ethereal <ethereal.visage@gmail.com> | |
| Mon, 21 Feb 2011 22:02:25 +0000 (21 15:02 -0700) | ||
| committer | Ethereal <ethereal.visage@gmail.com> | |
| Mon, 21 Feb 2011 22:02:25 +0000 (21 15:02 -0700) | ||
| tree | b9a09e94d27b5f71b733a5f2f1384a1e46709676 | treesnapshot (tar.gz zip) |
| parent | 8890860fee6cd24deda01b27aac959f09d8889e5 | commitdiff |
Decision time again, as per usual . . .
There are two possibilities that have been previously discussed for the SHM-
based communication system. One is to use a slightly "gappy" system, and to do
all reads and writes from/to the actual SHM itself; the other is to prepare
the packet data beforehand, and then copy the entire packet over to the SHM.
The first approach wastes a small amount of memory in the SHM (reducing the
buffer size by a small amount) but greatly saves on CPU time. The second is
far easier to implement and saves a small amount of memory, but takes far more
CPU time.
The question is, which one?
There are two possibilities that have been previously discussed for the SHM-
based communication system. One is to use a slightly "gappy" system, and to do
all reads and writes from/to the actual SHM itself; the other is to prepare
the packet data beforehand, and then copy the entire packet over to the SHM.
The first approach wastes a small amount of memory in the SHM (reducing the
buffer size by a small amount) but greatly saves on CPU time. The second is
far easier to implement and saves a small amount of memory, but takes far more
CPU time.
The question is, which one?