Re: [QGIS-Developer] QGIS Server plugins and thread safety

On Fri, 26 Oct 2018 at 00:28, G. Allegri wrote: > > Moreover The C API offers the opportunity to release the GIL (see for example > numpy [1]). For reference -- we do this also since QGIS 3.0. Every call to a QGIS (c++) API releases the GIL and reacquires after the call. This means it's

Re: [QGIS-Developer] QGIS Server plugins and thread safety

OK, single thread only for now. On Sun, Nov 19, 2017 at 5:39 PM Martin Dobias wrote: > Dealing with objects like map layers or project in non-main thread is likely > to end up badly. Just as a theoretical question: Why, if there are no static variables and everything (except layer rendering,

Re: [QGIS-Developer] QGIS Server plugins and thread safety

Python GIL doess't guarantee thread safety, and it only applies to python code. It only protects the internal state of the interpreter. Moreover The C API offers the opportunity to release the GIL (see for example numpy [1]). Giovanni [1] https://stackoverflow.com/a/36480941 Il giorno gio 25

Re: [QGIS-Developer] QGIS Server plugins and thread safety

I would go for multiprocess and stick to a single thread per-process. But David may have a better advice. Btw, it's nice to see a use case for Python Vector data providers :) On Thu, Oct 25, 2018 at 1:02 PM Radim Blazek wrote: > If we narrow down the environment to uWSGI (with multiple

Re: [QGIS-Developer] QGIS Server plugins and thread safety

If we narrow down the environment to uWSGI (with multiple threads enabled) running a Python application, which means that more instances of the same application may run in threads but never at the same time due to Python GIL (if I understand it well), is it still a problem? If we ensure that there

Re: [QGIS-Developer] QGIS Server plugins and thread safety

Hi Alessandro On Sun, Nov 19, 2017 at 10:34 AM, Alessandro Pasotti wrote: > Hi, > > mi recent experiments with multi-threaded python wrappers for QGIS server > showed a critical flaw in my original implementation of the server plugins. > > First, I want to stress that this is

Re: [QGIS-Developer] QGIS Server plugins and thread safety

Hi, IMHO, The multi process approach has to be preferred over multi-threading Some thought about it: Forking sever instance for each request is imho a bad idea as it is not scalable and defeat resource control. I think that it is not a problem by itself to consider the server engine as

Re: [QGIS-Developer] QGIS Server plugins and thread safety

Maybe I've found a simple and effective no-API-break solution: I'm working on a QThreadStorage based implementation of the server iface request handler that might be the simplest solution to this issue. Btw this is only one of the most obvious issues in the server thread safety, there are

Re: [QGIS-Developer] QGIS Server plugins and thread safety

I didn't follow, shared cache is a solved problem for the server? Luigi Pirelli ** * LinkedIn: https://www.linkedin.com/in/luigipirelli * Stackexchange:

[QGIS-Developer] QGIS Server plugins and thread safety

Hi, mi recent experiments with multi-threaded python wrappers for QGIS server showed a critical flaw in my original implementation of the server plugins. First, I want to stress that this is not a problem in FCGI server implementation but only if the server is used directly from python in a