💾 Archived View for tilde.pink › ~kaction › log › 2020-06-10.1.gmi captured on 2022-06-03 at 23:25:05. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

➡️ Next capture (2023-01-29)

-=-=-=-=-=-=-

About notifying parent process

Some time ago I decided to add to my preferred pdf viewer^1 feature to save and restore current page between program invocations. It already had command line option to open file at specified page, but provided no simple way to know at what was current page when it exited.

^1

I found variable that contains page number quickly, but how do I return its value to parent process? Standard streams were already used for something else, so after some though I found elegant (I think) solution: write page number to non-standard file descriptor^2:

^2

dprintf(4, "%d\n", num);

If that file descriptor is not open, nothing happens -- function call silently fails. If parent setup this descriptor to be output side of a pipe, parent will be able to read value from input side of that pipe. That is exactly what I did when implementing wrapper that saves and restores current page^3.

^3

After that I recalled that the most common reason software links with libsystem is desire to notify systemd that service finished initialization, e.g:

init();
sd_notify(1, "READY=1")
while (1) {
  process_incoming_request();
}

I have never seen situation when this is actually needed, but that is not the point. Point is that in many, many cases libsystemd could have been replaced with just at convention of notifications being written to a well-known file descriptor.

Simple, lightweight and non-invasive. Properties that are at odds with systemd project agenda.