Nginx mutli-threaded plugin

[Maxim Dounin]

Hello!

On Wed, Jan 02, 2013 at 10:37:48AM +0530, Fasih wrote:

> Thank you Maxim. Will try to see if I can get to the single threaded model.
> Basically when I was talking about accept_mutex, what I meant was, if the
> worker thread is busy with my cpu-intensive work, I would obviously want
> the other workers to take over. IIUC, if I have the accept mutex I am the
> one who will take the requests, is it possible that my worker plugin is
> caught up doing the work *and* has not released the mutex? In other words,
> is it possible that my CPU intensive operation prevents other workers who
> are free from taking requests with any configuration option
> enabled/disabled.

Accept mutex's job is to prevent multiple workers from accepting 
connections simulteneously, thus preventing unneded wakup of all 
worker processes for an accept() when new connection arrives.  
Accept mutex is released right after a wakup as soon as nginx 
reads list of events reported by kernel.  It's not a load 
balancing mechanism.

With a way things are normally done in nginx, busy workers are 
less likely to wait for kernel events and therefore less likely to 
get new connections (both with accept mutex enabled or accept 
mutex disabled), thus ensuring balancing between workers.

> On Wed, Jan 2, 2013 at 2:49 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> >
> > On Tue, Jan 01, 2013 at 11:57:30PM +0530, Fasih wrote:
> >
> > > Hi guys
> > >
> > > I need to write a plugin which does some CPU intensive work. I want to be
> > > able to create a thread which does some work and once done post an event
> > > into nginx thread via ngx_add_timer. I tried compiling my plugin with
> > > NGX_THREADS=pthread but that doesnt configure saying that the threading
> > > support is broken.  I can obviously switch to a single threaded mode but
> > > that would be significantly difficult for me and would prefer to use only
> > > as the very last resort.
> > >
> > > Can you please advice how to go about doing this? I am considering
> > pulling
> > > out the usage of 'ngx_event_timer_mutex' outside #if NGX_THREADS.
> > Frankly I
> > > am surprised how no other plugin had this kind of requirement, the
> > "broken
> > > support" commit has been there since quite some time now.
> >
> > Threading support as currently present was an experiment, and it's
> > broken for a long time (some very limited part of it is still used
> > on win32, but it's different story).  I wouldn't expect you'll be
> > able to work with threads without problems.
> >
> > > One final question, if I do the CPU intensive work in the nginx thread
> > and
> > > I have <cpu-cores> number of workers, how would the system behave? Will
> > > accept_mutex on/off change the behavior?
> >
> > Accept mutex only ensures no two processes try to accept new
> > connections at the same time, and it doesn't care how do you
> > handle requests.  Obviously enough it will change the behaviour,
> > much like in any other case.
> >
> > --
> > Maxim Dounin
> > http://nginx.com/support.html
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >

> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel


-- 
Maxim Dounin
http://nginx.com/support.html