Re: [libmicrohttpd] 答复：The resuming of a single connection and daemon not coordinate

[Christian Grothoff]

> 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

> ------------------------------------------------------------------发件
> 人：钱在晨(二败) <address@hidden>发送时间：2015年5月31日(星期日) 10:57收件
> 人：libmicrohttpd <address@hidden>主　题：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