Would it be possible to make libvips fork safe? #3577

Ah I see, that does sound a bit tricky.

john@banana ~/GIT/libvips/libvips (dzsave-direct) $ grep mutex_new */*.c | grep -v ">" | wc
     11      41     628

So I suppose those are the static mutexes in libvips. They'd each need a _shutdown() function, called from vips_shutdown(). There are some static threads too, they'd need something similar, and perhaps some static semaphores.

A harder problem could be g_once():

https://docs.gtk.org/glib/func.once.html

john@banana ~/GIT/libvips/libvips (dzsave-direct) $ grep -i gonce */*.c | wc
     20     119    1053

You might need to find some way to make them all resettable. Or maybe not? I'm unsure, you'd probably need to read all those init functions and check.

They'd each need a _shutdown() function,

Hum, would they? Assuming the threads using them are cleanly shutdown, the mutex should be left unlocked, no?

A harder problem could be g_once():

TIL.

It does indeed seem like a large enterprise. I will reach for workaround for now, I think in the application I care about Vips is infrequently used, so I might be able to roll with refoking being disabled once it has been used. That will require a way to check if vips_init() has been called.

Hum, actually I'm a bit confused here.

ruby-vips calls vips_init as soon as it's loaded: https://github.com/libvips/ruby-vips/blob/acbdf3e8f4084b930d02fd72e4efeba41ee86852/lib/vips.rb#L617-L621.

And I'm 100% certain loaded during boot in our app and continues to work after the initial fork. There must be more lazy initialization going on later.

Yes, the threads that libvips uses are created on demand, so mutexes stay in their inited-but-unused state until pixels are processed.

Ah, that makes sense.

I'll have to dig more into the library, but this is low priority for now, our usage in this app is limited, so I'll just use a workaround short term.

Thank you very much for your insights!

note will not work if VIPS_MAX_THREADS, it must be unset ...

note will not work if VIPS_MAX_THREADS, it must be unset ...

@SamSaffron The undocumented and unsupported VIPS_MAX_THREADS environment variable should not be used outside WebAssembly, see for example:
#3105 (comment)

And:

$ vips black x.jpg 100 100
$ VIPS_MAX_THREADS=4 vips autorot x.jpg x2.jpg --vips-concurrency=3 --vips-progress

thanks, another thing I discovered (when it comes to Linux forking).

Doing this in the parent appears to be safe, and can knock off ~4ms of warmup from the child only leaving the thread creation at 0.5ms which is cheap.

VipsOperation *black = vips_operation_new("black");
VipsOperation *avg = vips_operation_new("avg");
g_object_unref(black);
g_object_unref(avg);