On Mon, Mar 16, 2020 at 4:29 PM Christian Grothoff <[email protected]>
wrote:
> This seems kind-of OK (I personally think pthread_detach is always messy
> and in 99.9% of cases a bad idea).
Hm... Could you point the disadvantages of using detached threads? I'm a
little newbie with this feature of pthreads.
I'm going to use suspend/resume and pthread in requests that takes a long
time processing read-only data (e.g. report generation) that could block
the main loop, but "discard" them if the server stops.
hat you do need to (somehow) ensure
> is that you do MHD_resume_connection() (and let it finish) *before*
> calling MHD_stop_daemon().
>
The current design looks like this:
static void *bar_cb(void *cls) {
*MHD_resume_connection*(... con sent with cls above ...);
... calls the user-defined callback sent with cls above ...
pthread_exit(NULL);
return NULL;
}
// foo() is called inside a MHD_AccessHandlerCallback
int foo(... some params ...) {
... some param checking ...
*MHD_suspend_connection*(con);
ret =
pthread_create(detached_thread, NULL, bar_cb, cls);
if (ret != 0)
goto error;
ret = pthread_detach(detached_thread);
if (ret != 0)
goto error;
return 0;
error:
... some error handling ...
return ret;
}
The MHD_resume_connection() was called before calling the user-defined
callback to avoid "MHD_stop_daemon() called while we have suspended
connections". :-)
BTW I'm OK to remove the pthread_detach() if it could raise future problems
in my application.
--
Silvio Clécio
