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
------------------------------------------------------------------
发件人：钱在晨(二败) <address@hidden>
发送时间：2015年5月31日(星期日) 10:57
收件人：libmicrohttpd <address@hidden>
主 题：The resuming of a single connection and daemon not coordinate
Hi,
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