I guess I'm thinking in terms of a very different way I envisioned a network manager (I have thought about doing one in the past). I was thinking of ONE probe process sending probes on ALL interfaces. Actually, my idea for a network manager would have been a single monolithic process doing everything, except for threads or child processes to do stuff that might block execution.

The list of IP addresses that need to be configured, if/when the interface(s) they need to be configured on comes up. And in both times of up and down, that list might be dynamically changed by some means.

NCD is a more complex design with a lot of capability. That means a lot more reading. What I had thought of (in addition to the idea about how to express configuration that started this thread) was something with far less programmability than NCD ... and so it would serve only a limited scope of needs (my focus being on a high reliability data center ... not home laptops). I'm still catching up on it.

I still think in a different kind of logic, like "probe all networks" and "collect a list of all subnets seen" and such.

I hope you're not confusing operating system processes and NCD processes. NCD (badvpn-ncd) is a single OS-level process. It's a single-threaded event-driven process. The NCD processes do not actually run in parallel. That's just an illusion. When you say manager->start(...), the NCD process that gets created based on a process template still does everything on behalf of the same badvpn-ncd OS process - no additional threads and no child processes.

In other words, NCD is a single monolithic process doing everything (except for child processes - e.g. IP config commands, wpa_supplicant, VPN clients).

This "list" you can either hardcode into the NCD program, or you can make it an actual list and use foreach in NCD (see wiki). As far as its dynamic changing is concerned, I've already proposed how I could add easy run-time configurability to NCD. Any thoughts on that?

Have you even tried actually running NCD? Have you tried running the example programs? Just read the NCD wiki page, it provides a lot of examples. Try to make something yourself. It's not as complex as it seems at first.

Not I'm not. But thanks for asking, because that could have been possible. What I'm thinking of is a "task state" which can be a process or a thread, as the OS sees it, or a context (list signal handlers use), or just a data structure in the interpreter of a higher level language. So it's multitasking, as opposed to multiplexing. In multiplexing, you'd have one "event loop" (typically) that polls multiple sources of events and work states to see what to do. This is a practical way to program when all the events that can trigger work will only trigger non-blocking short time work. I use this model for things like a network traffic redirector which might have dozens of open sockets, all in non-blocking mode, of course. It eliminates the need to do thread merging, or locking data queues between threads. It's one task doing multiplexing.

Even if the "process" in NCD is just a struct you coded to manage the state of interpreting several instances of work, it's still a single work entity that is only working for one context. E.g. you could have a loop that wakes up every NN minutes and tests ONE interface, and have 8 of these as separate tasks for each of 8 interfaces (and create a new one for the 9th interface that arrives later). My orientation to programming would have ONE task with a list of interfaces to check, and it would check them all.

And maybe it's not even that ...

Not yet. I need to study it more and find spare machine time to try it out. I'll probably end up making a SlackBuild script for it when I do, and that will make it easy to build a package for Slackware. One alternate project I'll probably try first is the one where I make USB memory sticks that boot up a Slackware derivative. I already programmed in a means to search for what device the root filesystem is on since that varies from one machine to another. These will need to be able to do multiple static IP addresses (as configured when built, and possibly altered later on) as well as DHCP, per interface.

Right, that's exactly how NCD is implemented. It implements tasks by multiplexing.

Are you saying there's an issue with such an approach? What is it then? Is there something you'd want to do but this paradigm is preventing you from? I think it's a very good approach in the domain of network configuration.

But then it would be much harder for this interface-checking thing to communicate the results. In my model, it's as simple as a statement changing state between down and up, and when up, exposing variables with various results. If you go for something more imperative, the automatic reverse-execution is no longer possible, which makes writing correct hotplug-aware network configs much more difficult; for instance, you are no longer automatically protected from various resource leaks.