FLTK as a service.

37 views
Skip to first unread message

Nikolay Tomov

unread,
Aug 5, 2025, 2:35:11 PMAug 5
to fltk.general
I'm building some apps (still in early stage of development). They are going to run on Linux and Windows. I ahve chosen FLTK because it's light weight and speed. As most of the apps will load the libraries dynamically, I'm thinking of making the FLTK libraries run as a service in the OS, and allow me to hook to the service, to avoid loading the same so/dll again and again (that's the reason not to statically link to them as well). Have you considered to make FLTK service, so the resource usage is minimized if more than 1 program is using them?

Albrecht Schlosser

unread,
Aug 6, 2025, 9:20:47 AMAug 6
to fltkg...@googlegroups.com
On 8/5/25 19:55 Nikolay Tomov wrote:
> I'm building some apps (still in early stage of development). They are
> going to run on Linux and Windows. I ahve chosen FLTK because it's
> light weight and speed.

Great, welcome to FLTK, and thanks for choosing FLTK.

> As most of the apps will load the libraries dynamically, I'm thinking
> of making the FLTK libraries run as a service in the OS, and allow me
> to hook to the service, to avoid loading the same so/dll again and
> again (that's the reason not to statically link to them as well). Have
> you considered to make FLTK service, so the resource usage is
> minimized if more than 1 program is using them?

Hmm, I don't understand the difference between making FLTK a service or
to just use the shared libraries. Loading shared libraries into memory
only once is the whole purpose of building shared libraries in the first
place. What do you mean by "hook to the service" ?

The only difference I can imagine is the first loading of the shared
libraries. If you want to avoid the (minimal) overhead of loading the
libraries for the first time, then you might want to create a dummy
("service") program that gets started early, loads all FLTK shared libs,
and does ... nothing.

Well, if that's what you want to do, it's up to you, feel free to do
this (and report what you did). I don't believe that we (the FLTK Team)
are interested in such a feature. Unless I misunderstood what you want
to achieve... (?)

Nikolay Tomov

unread,
Aug 8, 2025, 5:46:30 PMAug 8
to fltk.general
When I load the shared libraries, each of the processes loads the called library and loads it in it's memory space. My idea is to have only one instance that is shared by all the apps and is started either on system start, or by the first app that needs it. I came to think of it when I compared what my apps load in Linux and what they do in Windows. In Windows (where I first started to develop the apps I used Win32). When I decided to port one of the apps for Linux Mint I decided that it will be great no matter the OS the apps look the same. So I came across FLTK and ported the code to use it. It's going slow - now I have to learn the library and how to do the things I did with Win32. Anyways - the apps for Windows were using less memory than the FLTK versions. It was normal, as I had to load the FLTK libraries, but I started to wonder how to offload the dual/triple load of each of the dlls in the memory of the program and do it once and be able to use it as a service, something similar to what Win32 is doing - loads once and then servers any number of programs that need a window drawn. The other possibility is I don't know how to use the shared libs.

e...@ohnezutaten.de

unread,
Aug 9, 2025, 8:26:50 AMAug 9
to fltk.general, Nikolay Tomov
Hi Nikolay,

Am Freitag, 8. August 2025, 22:12 schrieb Nikolay Tomov:
> When I load the shared libraries, each of the processes loads the called
> library and loads it in it's memory space.

No. At least not by default. It is more complex: loading a shared library
means the read-only part of a shared library is *mapped* into the
application's address space (valid for the main application itself as well).
And only if the application touches any code in this mapped area (by calling a
subroutine for example), Linux will load the corresponding *page* from the
library's image file into the memory on demand. And if the same part of the
shared library's image file was already read into memory due to an access by a
different application using the same library, Linux just uses this page twice
(e.g. no new filesystem activity happens).
So I think, the OS already does in background what you try to invent.

(And yes, there is an impact to this OS behaviour due to link time flags like
'Bind Now' (-z) and run-time settings like ASLR).

> [...] loads once and then servers any number of programs that need a window
> drawn.

That's exactly for what shared libraries are made for.

jbo


Albrecht Schlosser

unread,
Aug 9, 2025, 8:48:25 AMAug 9
to fltkg...@googlegroups.com
Thanks. I couldn't have said it better.

Reply all
Reply to author
Forward
0 new messages