> On 05/31/2015 08:37 AM, 钱在晨(二败) wrote: > 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
MHD uses multiple *internal* `struct MHD_Daemon` instances when you create a thread pool (one per thread in the pool). Thus, we don't need to lock in this case, as there is only a single thread that can ever call 'MHD_suspend_connection' on a particular daemon. Given the current logic, I'm not sure locking is required at all for 'MHD_resume_connection', except maybe because 'daemon->resuming' is non-volatile and some memory model might say that the write is only visible with locking (I'm not sure what the C memory models say about IPC with pipes for signaling). Anyway, so calling the suspend/resume functions should be 'safe' (as long as you do the suspend from within the worker pool thread) without the locking. That said, the fact that 'daemon->resuming' is NO afterwards might be explained because you're looking at the 'external' master daemon (which in thread-pool mode only does 'accept()' and dispatches the load to the 'worker' threads), while the 'resuming' flag is set for the worker daemons. That doesn't explain why any of this caused you trouble in the first place, but might help you understand what's going on. For further help, the best way would be for you to provide some simple example / testcase that demonstrates the problem. Then we can find out if it is a bug, or if you're not using the API correctly for some reason. Happy hacking! Christian > ------------------------------------------------------------------发件 > 人：钱在晨(二败) <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 >
signature.asc
Description: OpenPGP digital signature
