Description: When I create the component context like below Reference< XComponentContext > xContext(::cppu::bootstrap()); The soffice is running and I am opening some large file or corrupted file which eventually hang the soffice or takes too much of time to process it, In that case I need to wait some time and kill the soffice if the work is not completed in the defined time. The problem is: I am running multiple instances of my applications to achieve the parllel processing which launches the multiple soffice instances and , I don;t know which soffice is taking time/hung to kill it. So it is nice to have a process id returned when I called Reference< XComponentContext > xContext(::cppu::bootstrap()); Steps to Reproduce: 1.Launch the soffice with Reference< XComponentContext > xContext(::cppu::bootstrap()); in your sample application. 2. Load the heavy document using loadComponentFromURL which takes some minutes, 3. when this takes time , try to gracefully kill the soffice and come out of it. But there is no way if multiple soffice instances are running. Actual Results: No PID of the soffice available after launching it via Reference< XComponentContext > xContext(::cppu::bootstrap()); Expected Results: Should return the PID maybe via XComponentContext Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Sample program and discussion with Mike can be found here. https://ask.libreoffice.org/t/terminate-soffice-bin-soffice-exe-when-loadcomponentfromurl-is-taking-time-or-hung/123713/3
Stephan, do you have a suggestion? We have --pidfile= command line argument (and respective machinery to write own pid into that pidfile: Desktop::Main, see GetPidfileName). But cppu::bootstrap has no arguments. I think if we could have an environment variable for pifdile name maybe? Then initiating program could set that variable prior to bootstrapping, so the child soffice process would be able to know where to create the file, which the parent could then read? Of course, implementing an interface, which the context could implement, is also an option.
Instead of the convenience cppu::bootstrap, you can use functionality that allows you more control over the spawned LO process, see e.g. unotest/source/cpp/officeconnection.cxx.