Archon- / mongoose

Automatically exported from code.google.com/p/mongoose
MIT License
0 stars 0 forks source link

Flag to terminate handler #351

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
A (long-running) handler needs to know when mongoose is about to stop. If the 
handler does not return, mongoose does not terminate properly.

Suggested solutions:
1) add a new function mg_is_running(struct context*) that returns stop_flag, or
2) make mg_write() to fail (i.e. return -1) when stop_flag is set

I think I prefer the second alternative because the connection is available to 
the handler anyway, while the context is not. Writing 0 bytes of data just to 
check the stop_flag should then be accepted behavior.

Original issue reported on code.google.com by kai.nick...@gmail.com on 6 May 2012 at 11:31

GoogleCodeExporter commented 9 years ago
This could easily be done with a hook in case the master thread exits. This 
hook would solve several other issues on the list as well. The user callback is 
called with an event MG_EXIT_MASTER and may be used to stop/cancel the 
operations of worker threads or other processes (CGI/DB/..).

e.g., at DEBUG_TRACE(("stopping workers")) insert something like

  memset(&request_info, 0, sizeof(request_info));
  request_info.user_data = ctx->user_data;
  if (ctx->user_callback) {
    ctx->user_callback(MG_EXIT_MASTER, (struct mg_connection *) 0, &request_info);  
  }

Original comment by bel2...@gmail.com on 7 May 2012 at 7:26

GoogleCodeExporter commented 9 years ago
I would go with number one but have the parameter take a mg_connection 
structure. The mg_is_running function is expected to be called from within a 
long running response which should have a connection associated with it.

@bel I would expect to receive the MG_EXIT_MASTER callback only once all the 
worker threads have actually stopped. The patch I have in Issue 345 will soon 
be updated with master thread entry and exits. Would a MG_STOPPING_MASTER be 
needed? Thus MG_ENTER_MASTER is called when stop_flag is set to 0, 
MG_STOPPING_MASTER is set when stop_flag is set to 1, and MG_EXIT_MASTER is 
called when stop_flag is set to 2.

Original comment by jmucchie...@gmail.com on 10 May 2012 at 4:19

GoogleCodeExporter commented 9 years ago
I use an augmented clone of mongoose and have these two functions exported for 
precisely this purpose (the custom code is serving very long running requests, 
and the custom code both needs to see when mongoose is shutting down 
(mg_get_stop_flag()) and signal the mongoose to shut down (mg_signal_stop()), 
e.g. when an fatal error occurs in the custom code.

Code snippet from mongoose_ex.c:

int mg_get_stop_flag(struct mg_context *ctx)
{
    return ctx && ctx->stop_flag;
}

void mg_signal_stop(struct mg_context *ctx)
{
  ctx->stop_flag = 1;
}

Original comment by ger.hobbelt on 12 May 2012 at 5:42

GoogleCodeExporter commented 9 years ago

I think a callback at DEBUG_TRACE(("stopping workers")) is required. At this 
location it tells asynchronous operations that the server is supposed to shut 
down, so these operations/threads could be canceled. If a worker thread is busy 
and no one tells it to cancel the operation one will not reach the point of 
DEBUG_TRACE(("exiting")).

I don’t know if there is need for a second callback at 
DEBUG_TRACE(("exiting")) when all threads actually finished - maybe yes, since 
it is an asynchronous shutdown one might need to know when the shutdown starts 
and when it is completed. 

Original comment by bel2...@gmail.com on 21 May 2012 at 3:02

GoogleCodeExporter commented 9 years ago
Submitted 
https://github.com/valenok/mongoose/commit/15a0d819ede70398db936977ddb0ecf6cf32a
195, thanks!

Original comment by valenok on 16 Aug 2012 at 4:26