Flutter and linux

Question

I want to create a flutter plugin for Linux. I don't know very well C++ but I want to try. Is it a good idea to create shell command in C++ ? For example if I need Bluetooth devices and I do

auto pPipe = ::popen("bluetoothctl scan on", "r");

And read ouptut stream to get scan result, is it a good practice in C++ ? Bluetooth is for example, but it would be wifi, 4G, etc ...

Solution

There's nothing inherently wrong with using popen, but it's a pretty heavyweight approach, and if you do it often for relatively transient commands you'll probably be putting more load on the system than another app that embeds or links code to do something equivalent. Separately, using popen may or may not make it easier to maintain your program - depending on whether the tools you use change their command line options, change their output, and remain available on the distros you want to support etc..

Comments

[datenwolf]

popen is not very heavyweight. In general spawning processes on Linux is comparatively lightweight (it's no more expensive than creating threads!). And the creation of a pipe and dup2-ing the filedescriptors is less work than open. execve can add substancial load, but that's mostly down to poorly written programs that pull in a ton of crap. If you execve a small (<16kB), statically linked binary, it's almost cheap.

[Tony Delroy]

@datenwolf: I've done similar things with conky calling nvidia-settings and other programs for CPU speeds, temperatures etc. - it's massively more resource intensive than it needs to be - whether that matters to you or not will depend on many factors. Consider the alternatives - linking some library for bluetooth/Wifi/whatever support (OP asks about the general case, not only bluetoothctl), finding an OS call you can use, looking in /proc or /dev or similar: they're all massively more efficient than starting a transient process each time.

[datenwolf]

The overhead stems mostly from the complexity of starting the program being execveed; that is, resolving all the dynamic library dependencies, loading all the crap, and calling constructors. It not the fork and execve itself that have a lot of cost. On modern machines Linux can do thousands of forks a second without breaking a sweat. Yes, reading directly from /proc and /sys is more performant, and depending on what you're trying to achieve also more stable. But it defeats the *nix way of composing simple programs.

[Tony Delroy]

@datenwolf "The overhead stems mostly from the complexity of..." - so? Overhead is overhead. I get that you're proud of Linux process startup, but apportioning blame here or there's just not relevant to the overall truth of my saying it's a "pretty heavyweight approach". And the UNIX composition business should be understood in context - fine for bash scripts or longer-running pipes, but it's not a best practice in C++ to repeatedly pipe out to e.g. egrep, ls, date, curl etc. instead of using OS/library versions/alternatives when you're "doing it often" - per my answer.

[datenwolf]

IMHO it's a perfectly fine approach to pipe out to egrep and similar. A StackOverflow comment offers too little space to explain it in full, but depending on the task at hand, the subworker process at and, and the memory access pattern, splitting off the work into a separate process can hugely improve the performance (to understand why, you must look at how TLBs are managed and that page faults effect the whole process and not just the thread they happen in).

[datenwolf]

@TonyDelory: I'm not making this statement out of some "theoretical" view. As a matter of fact, I'm currently reworking some of my programs into a multi-process design (which previously was multi-thread and libraries) due to the performance benefits. And, by doing dome trickery on the stdio file descriptors even make them composable in scripts, yet for integration into a "coherent" application it's strung together by machine native code compiled from C++.

[datenwolf]

Also it would be madness to reimplement the whole netlink stuff, or use a library for interacting with Linux IP stack configuration. The idiomatic way is to pipe to the /sbin/ip tool.