Why does the clock need a shared memory segment?

Question

This is a combination of programming and Linux question but I think it suits better here.

I am writing an application that works with ipcs (shared memory segments) and after each running I am checking if any ipcs are left using the bash command ipcs. I noticed a lot more than I created so I thought they are part of the system software.

i decided to examine each one and see where it is connected. After closing the process each one is connected I noticed that one of the processes that is attached to a shared memory segment is the system clock. By system clock I mean the clock that tells the time down right of the panel (or up depending on how you set up things) and not the CPU clock. Why, out of all the processes that the system runs, does the clock need a shared memory segment?

Answer 1

By system clock I mean the clock that tells the time down right of the panel

"System clock" generally refers to the clock maintained by the kernel; applications such as date and GUI clocks such as the one you refer to make calls to it like this.

Why, out of all the processes that the system runs, does the clock need a shared memory segment?

There's probably dozens of different GUI and DE based clocks available for linux so there's no way to say specifically. This implies it involves multiple processes which is certainly not necessary for a GUI clock, but if it is integrated with the desktop, who knows -- it could also possess some functionality you haven't discovered yet.

You have a lot of choices, IPC wise, when programming. What method you use depends on the exact requirements but also perhaps some personal preference. I'm more a sockets n' serialization kinda guy, but shared mem is very popular; when I run ipcs -a I get a few dozen entries under "Shared Memory Segments". Interestingly, if I run it on a headless system I get none, so presumably those are all related to GUI applications. Glib and D-bus may have facilities built on shared mem used by such programs.