You said "another thread could mg_wakeup_server_ex() to push the result of the long-running operation to the respective connection"
I am finding that mg_wakeup_server_ex() does not exist in mongoose 5.3. I am only able to get source for 5.3. Is this function only in 5.4? Can I have access to that source to try it out? I tried calling mg_wakeup_server() (which does exist in 5.3) from a long running user callback in another thread, but find that the mg_connection structure has gone bad when I try to write the response. Thanks, Scott On Thursday, August 7, 2014 3:05:06 PM UTC-6, Sergey Lyubka wrote: > > Hi Scott, > > > On Thu, Aug 7, 2014 at 9:24 PM, Scott Ellis <[email protected] > <javascript:>> wrote: > >> Hi Sergey, >> Thanks a lot for your responses. I have a follow up question. You said >> "long-running >> operations must be moved to dedicated threads." Does mongoose do this >> internally? I.e. if a client requests a large file that takes a few seconds >> to serve up, are new requests blocked until the time consuming request is >> complete? >> > > No, mongoose does not start threads by itself. > > If a request to a large file comes in, mongoose opens it, starts to read > and append it's data to the output buffer. mg_send_data() and mg_printf() > data do not actually send data to the socket (because that can block), they > just append data to the output buffer. When serving files, mongoose never > appends more then a certain limit to the output buffer, so IO buffer > doesn't grow large. > > If mongoose appended data to the output buffer and reached a limit, but > file is large and has more data, mongoose gives up until the next iteration > of event loop (see tranfer_file_data() > <https://github.com/cesanta/mongoose/blob/b67b6188110285bec6fe065a613433b788da3afe/mongoose.c#L4637> > > function). > > By doing that flow control, mongoose doesn't need to resort to other > threads, and it's runtime memory consumption stays as low as required. > That's IO bound scenario. > > However there could be situations when e,g, CPU-intense, long-running > computation is required to server the request. Flow control wouldn't help, > so to keep event handler from blocking, computation should be done in a > separate thread. That CPU bound scenario I was referring to in my previous > message. > > Note about some caveats with multithreaded approach. When each request is > handled by a separate thread, a programmer doesn't need to bother with > long-running operations: OS's thread scheduler will make sure to give CPU > to every thread (connection). That comes at a cost of having many threads > -- such a server is easy to DoS by creating many idle connections (with > e.g. netcat). Another, more serious issue is that IO functions are actually > write directly to the socket, and their behavior is non-deterministic. > Consider the situation: > > lock_some_resource_for_example_database(); > write_data_from_database_to_client(); // can block in multithreaded > mongoose, never blocks in single-threaded > unlock_database(); > > The second is usually fast, but due to the nature of TCP could take a very > long time in some situations. If that happens, locked resource can stall > all other connections even in multithreaded server. With non-blocking, > async approach that won't happen. > > Does that make make sense? > -- You received this message because you are subscribed to the Google Groups "mongoose-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
