[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uwsgi
Subject:    Re: [uWSGI] threads
From:       Bo Lorentsen <bl () lue ! dk>
Date:       2015-12-10 16:11:06
Message-ID: 5669A41A.1040007 () lue ! dk
[Download RAW message or body]

On 12/10/2015 02:16 PM, Roberto De Ioris wrote:
>> Hi ...
>>
>> I have been looking into the documentation for more hints on the threads
>> part of uwsgi. I am planning on creating a C++ plugin for uwsgi and like
>> to know a little about how this will work while using the thread model.
>>
>> I really like the idea of not reinventing all the inner work of uwsgi (I
>> have done that before, but uwsgi have done a much better job) :-)
>>
>> I off cause need :
>>
>> enable-threads
>>
>> And I guess that this means that plugin will be loaded and I quess that
>> the "init" function will be executed ones (in the same startup thread as
>> when loading the plugin) ?
>>
>> All following requests are send using a thread per request, and I quess
>> they are all there are in a pool of threads defined by :
>>
>> threads=nn
>>
>> there are four stack size config entries ?
>>
>> thread-stacksize
>> threads-stacksize
>> thread-stack-size
>> threads-stack-size
>>
>> Do they all do the same ?
>>
>>
> Hi, enable-threads is useful only if you need to embed something that
> needs to generate some special state for each process.
That is what I am trying to do :-)

Currently I have a system that maintain a set of sessions, that need to
be found (cookies you know) on each request but in a common memory pool
(I like speed).

The same go for a DB connection pool, and other common resources like
cache :-)
> Generally speaking, the wsgi_request structure is per-thread so, unless
> you need to hack on very specific parts of the uWSGI core you do not need
> locking.
If I understand correctly, if "enable-threads" is not enabled only one
thread will enter my plugin request function, and therefore no lock is
needed ? But that would only scale if no common resources was needed
(good old CGI :-))
> You may want to look at cutelyst (c++/QT):
>
> http://cutelyst.org/
>
> that uses uWSGI as the serving core
I have been looking at this project, and it is inspiring :-)

Currently I have made my own SCGI/HTTP backend, that is multi-threaded
and handles things like sessions, DB, JsonRPC and RESTful access. But it
would make much more sense to use uWSGI as network core, as all kind of
problems are solved in it and it seems to scale well and have community
focus.

But by doing that I hand over all thread handling to uWSGI, and I
therefor need to know a bit more about what is going on inside it. Next
step will be reading code :-)

/BL
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
[prev in list] [next in list] [prev in thread] [next in thread]