Hi Evgeny, Hi all, Firstly, protecting MHD_run made the job, the crash disappears and valgrind is happy. Thank you for that efficient support.
Secundly, I'm still seeing and investigating an issue. Sometime, the queued response (MHD_queue_response) is not sent. Here again, I think that it is a race condition. The issue is surely on my side. Then some responses to your questions below. [snip] > >>> > >>> flags = MHD_USE_EPOLL > >>> | MHD_ALLOW_UPGRADE > >>> | MHD_USE_TCP_FASTOPEN > >>> | MHD_USE_NO_LISTEN_SOCKET > >>> | MHD_ALLOW_SUSPEND_RESUME; > >> > >> Do you use suspend/resume of connections? > > > > yes for websocket upgrade but it is not relevant in the case. > > Don't you use MHD built-in "upgrade" functions? Good question. I had not noticed before: I have both options MHD_ALLOW_UPGRADE and MHD_ALLOW_SUSPEND_RESUME. When I first implemented websocket using MHD, I used the suspend/resume behaviour. Is it still needed? I am now using MHD_create_response_for_upgrade for that purpose. However, at the moment, the program suspend the connection for the time it processes the request. That is the reason way MHD_run were called from multiple threads. [snip] > Please share you results. > We are close to releasing the next MHD version and want to make sure > there are no know bugs in the code. Still investigating one issue. > I'm wondering, why do you run the same MHD instance in different > threads? Every MHD_run() processes *all* connections served by > particular MHD instance. This looks like work duplication (or > multiplication). If you process specific connections by each thread > and you add connections to MHD by MHD_add_connection(), just use > thread-specific MHD instance so you will always know which > connections are processed by MHD_run(). I could answer but here is what I prefer to write. I also think that if every one made same choices the world would be peaceful. But new problems, new solutions, new men, new ideas, ... Why have you written MHD in C and not in PASCAL?
