continued... I think I find the reason. In the function MHD_resume_connection(), daemon.c: line 1601
It requires the MHD_USE_THREAD_PER_CONNECTION option to lock the cleanup_connection_mutex, but int my program, I use the options like "MHD_USE_SELECT_INTERNALLY | MHD_USE_POLL | MHD_USE_DEBUG| MHD_USE_SUSPEND_RESUME | MHD_USE_PIPE_FOR_SHUTDOWN" and the thread pool settings "MHD_OPTION_THREAD_POOL_SIZE, 20".May I ask why only MHD_USE_THREAD_PER_CONNECTION requires the lock? I want to use the threadpool but it seems risky to use MHD_resume_connection and MHD_suspend_connection.Look forwards to your reply. Best Regards,Jason ------------------------------------------------------------------发件人：钱在晨(二败) <erbai....@taobao.com>发送时间：2015年5月31日(星期日) 10:57收件人：libmicrohttpd <libmicrohttpd@gnu.org>主 题：The resuming of a single connection and daemon not coordinateHi, Is there any situation that in the function resume_suspended_connections(), connection->resuming and connection->suspended are MHD_YES, but daemon->resuming is MHD_NO?My program uses one thread to produce data and a callback function in another thread (in the threadpool of libmicrohttpd) to return the produced data. The producing-data thread need wait until new data's coming. So I use MHD_suspend_connection in the callback function if no data to send and MHD_resume_connection in the producing-data thread when data is ready. But the program does not work because in the end in the function resume_suspended_connections(), the daemon->resuming is MHD_NO. In the meanwhile, there is actually a suspended connection in the daemon->suspended_connections_head. I check the status and find that the suspended connection with resuming: MHD_YES and suspended: MHD_YES, but the daemon->resuming is MHD_NO. I don't know if I explain the issue clearly. Is it normal or abnormal that daemon->resuming with the value MHD_NO makes a previously suspended connection cannot be resumed?Best Regards,Jason
<<attachment: MHD_resume_connection.jpg>>
