Skip to content

Latest commit

 

History

History
112 lines (79 loc) · 3.83 KB

README.md

File metadata and controls

112 lines (79 loc) · 3.83 KB
Raw

Name

lua-resty-treadpool - access Ngnix thread pools from Lua

Table of Contents

TODO

Status

This module is a proof of concept, the API is not fixed and implementation is licely to contain bugs.

Do not use in production!

Synopsis



Description


Since version 1.7.11, Nginx provides a thread_pool directive
that makes possible to offload blocking operations out of the regular
non-blocking I/O loop. In some situations this can lead to massive speedups.


This modules expose a Lua API to leverages these thread pools from the
lua-nginx-module. Using thread offloading from Lua makes possible to:


    

  • Use blocking I/O libraries (database access, message queue, ...)
    • 

  • Use blocking file I/O
    • 

  • Offload CPU intensive tasks
    • 



Keep in mind however that it is not a silver bullet for every problem, and
threads have their own limitation and also some overhead.


Dev notes


As stated previously, this module is currently a PoC, and a lot of issues still
need to be addressed. This section list some of open questions about design and
implementation.


Integration with lua-nginx-module


This module is deeply integrated into the regular Lua module internals, much
deeply than the current public API allows.


Also, the lua states are currently raw states, and do not have access to any
ngx.* APIs (lot even logging). Ideally, at least some APIs should be
available from worker threads (log, re, shared caches and other utility
functions), but most of other APIs don't make sense in this context (socket
for instance, as threads don't have event loops).


I'm not sure yet if such integration is possible without embedding this module
directly into lua-nginx-module.


Coroutine handling


Currently each task creates its own lua_State so when the code yields and is
resumed after, it can be scheduled on any thread of the pool. This is terribly
inefficient.


There is several ways to solve that:


    

  • Make one state per thread and lock the thread while the task is paused, but
this limits the thoughput of the thread pools
    • 

  • Make a state pool and allocate tasks using it before scheduling them on any
thread. This may cause a memory explosion as it can create len(queue) + thread count states in worst case
    • 



Copyright


Copyright (c) 2016, Julien Desgats
All rights reserved.


Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:


    

  1. 

    Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
    

    2. 

  2. 

    Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
    

    3. 



THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.