On 14 March 2017 at 23:21, Evgeny Grin wrote:
> MHD_get_fdset() may return MHD_NO if epoll FD is too high to fit fd_set
> or if MHD_get_fdset() erroneously called for daemon with
> MHD_USE_THREAD_PER_CONNECTION option.
Sorry, you are wrong.
src/microhttpd/daemon.c
660 int
661 MHD_ge
On 15.03.2017 12:10, Vitaliy T wrote:
> On 14 March 2017 at 23:21, Evgeny Grin wrote:
>> MHD_get_fdset() may return MHD_NO if epoll FD is too high to fit fd_set
>> or if MHD_get_fdset() erroneously called for daemon with
>> MHD_USE_THREAD_PER_CONNECTION option.
>
> Sorry, you are wrong.
>
> src
On 15 March 2017 at 12:10, Vitaliy T wrote:
> Sorry, you are wrong.
Sorry, misread POLL vs EPOLL and I was wrong. Corrected information is below.
Further investigations shows me that called with wrong
MHD_add_to_fd_set_() parameters from MHD_get_fdset2():
913 int
914 MHD_get_fdset2 (
Seems to be I have found the root of the problem.
When I call MHD_get_fdset2() the values are next:
1. daemon->epoll_fd == -1 (as I said before).
2. daemon->worker_pool[0].epoll_fd == 7 (as it was set initially).
Someone should fix this, because at the moment I don't know how to do
this correctl
On 15.03.2017 8:43, Vitaliy T wrote:
> On 14 March 2017 at 23:30, Evgeny Grin wrote:
>> You don't need to restore timeout value. It's not changed if you use
>> suspend/resume.
>> Timeout timer is restarted after each resume of connection.
>
> My situation is:
>
> 1. I set MHD_OPTION_CONNECTION_T
Thanks for report!
Yes, MHD_get_fdset2() do not handle situation with thread pool as it
designed to be called from user code only for daemons running external
select.
Fixed in master by return always MHD_NO for daemons with internal
select()/poll()/epoll.
Also now MHD_run() and MHD_run_from_select(
On 15 March 2017 at 12:58, Evgeny Grin wrote:
> Why do you want to play with timeout during connection suspend?
> Function description explicitly state:
> "Suspended connections will NOT time out; timeouts will restart when the
> connection handling is resumed."
That's right. This is why after re
On 15 March 2017 at 13:29, Evgeny Grin wrote:
> Fixed in master [...]
Thank you!
Now suspend/resume working out of a box for both epoll & select for
MHD_USE_XXX_INTERNALLY.
The bad news, there is regression for
MHD_set_connection_option (connection, MHD_CONNECTION_OPTION_TIMEOUT, timeout)
Pr
The patch is below.
diff --git a/src/microhttpd/connection.c b/src/microhttpd/connection.c
index f192a1bb..bc1e2abc 100644
--- a/src/microhttpd/connection.c
+++ b/src/microhttpd/connection.c
@@ -1406,7 +1406,8 @@ MHD_connection_update_event_loop_info (struct
MHD_Connection *connection)
Another version, variant for MHD_connection_handle_idle().
Short description:
Inside the function MHD_connection_handle_idle() between the loop and
later calling MHD_connection_update_event_loop_info() a lot things may
happen.
diff --git a/src/microhttpd/connection.c b/src/microhttpd/connection.c
On 15 March 2017 at 13:35, Vitaliy T wrote:
> I suppose we may close the question in the next way. I will implement
> everything as I want, e.g. will made local patch to MHD and will test
> within some kind amount of time (weeks, months). And in the case if I
> would like see this feature in MHD-c
On 15.03.2017 13:35, Vitaliy T wrote:
> On 15 March 2017 at 12:58, Evgeny Grin wrote:
>> Why do you want to play with timeout during connection suspend?
>> Function description explicitly state:
>> "Suspended connections will NOT time out; timeouts will restart when the
>> connection handling is r
On 15.03.2017 14:28, Vitaliy T wrote:
> On 15 March 2017 at 13:29, Evgeny Grin wrote:
> Thank you!
>
> Now suspend/resume working out of a box for both epoll & select for
> MHD_USE_XXX_INTERNALLY.
Suspend/resume logic wasn't changed.
They should work as before.
>
> The bad news, there is regre
Could you provide an example code, which you are trying to fix?
--
Best Wishes,
Evgeny Grin
On 15.03.2017 15:13, Vitaliy T wrote:
> The patch is below.
>
> diff --git a/src/microhttpd/connection.c b/src/microhttpd/connection.c
> index f192a1bb..bc1e2abc 100644
> --- a/src/microhttpd/connection.
On 15 March 2017 at 20:17, Evgeny Grin wrote:
> If you resume connection - it timeout timer will be restarted. So, right
> after resume connection should not timeout.
> [...]
> Sorry, still unclear for me, why do you need custom timeout connected
> with suspend/resume. And what is not working.
My
On 15 March 2017 at 20:41, Evgeny Grin wrote:
> Could you provide an example code, which you are trying to fix?
I don't think that it will help somehow. I can explain it.
2732 int
2733 MHD_connection_handle_idle (struct MHD_Connection *connection)
2734 {
2735 struct MHD_Dae
Yep, you are right, this patch is more correct.
"suspended" should be set by user callbacks called in this function, so
code must check for suspended before doing other thing.
--
Best Wishes,
Evgeny Grin
On 15.03.2017 16:00, Vitaliy T wrote:
> Another version, variant for MHD_connection_handle_i
Actually we should call MHD_connection_update_event_loop_info() in any
case after processing of data.
I already applied some patches to master. Check whether it helps.
--
Best Wishes,
Evgeny Grin
On 15.03.2017 21:41, Evgeny Grin wrote:
> Yep, you are right, this patch is more correct.
> "suspend
I mean show user code that works incorrectly with MHD.
--
Best Wishes,
Evgeny Grin
On 15.03.2017 21:37, Vitaliy T wrote:
> On 15 March 2017 at 20:41, Evgeny Grin wrote:
>> Could you provide an example code, which you are trying to fix?
>
> I don't think that it will help somehow. I can explain
On 15 March 2017 at 20:34, Evgeny Grin wrote:
> Suspend/resume logic wasn't changed.
> They should work as before.
Well, release versions from 0.9.52 including to 0.9.50 (may be early)
will not start calling DH callback until there is explicit call to
MD_run[_from_select]() is provided. Resumed c
We already have specialized function MHD_get_connection_info().
Now it can return timeout value. ;)
--
Best Wishes,
Evgeny Grin
On 15.03.2017 17:06, Vitaliy T wrote:
> On 15 March 2017 at 13:35, Vitaliy T wrote:
>> I suppose we may close the question in the next way. I will implement
>> everyth
On 15 March 2017 at 22:09, Evgeny Grin wrote:
> We already have specialized function MHD_get_connection_info().
> Now it can return timeout value. ;)
Thank you!
--
With Best Regards,
Vitaliy V. Tokarev
On 15 March 2017 at 21:52, Evgeny Grin wrote:
> Actually we should call MHD_connection_update_event_loop_info() in any
> case after processing of data.
> I already applied some patches to master. Check whether it helps.
About commit ..bcfacf404
Seems same for me. Same place, same issue with
That's why I asked about user code example. I can't test what we trying
to fix.
Did you test it or only review?
Seems that MHD read data from network after you suspended connection,
which cause overflow buffer overflow and error response.
You issue should be fixed by afb221c32aeeb2731e3b5362cc4ff89
On 15 March 2017 at 23:54, Evgeny Grin wrote:
> That's why I asked about user code example. I can't test what we trying
> to fix.
I understand you wish clearly. I will provide the code tomorrow.
> Did you test it or only review?
I am always do test the code, because there are might be regressio
Hello Vitaliy,
Sorry, but after applying that changes, could you share a small example
showing how to use MHD with external epoll? If so, it could be very useful
for the community, and MHD core could distribute it in the examples
directory. :-)
On Wed, Mar 15, 2017 at 6:29 PM, Vitaliy T
wrote:
26 matches
Mail list logo