libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] [PATCH]: MHD_connection_update_event_loop_info sends


From: Evgeny Grin
Subject: Re: [libmicrohttpd] [PATCH]: MHD_connection_update_event_loop_info sends INTERNAL_ERROR for suspended connections
Date: Fri, 17 Mar 2017 16:20:50 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 17.03.2017 15:59, Vitaliy T wrote:
> On 17 March 2017 at 15:43, Evgeny Grin <address@hidden> wrote:
>> You don't need to make this check only inside callback function. If you
>> suspend connection and resume it later - connection conditions are not
>> changed, you will not get any new information in callback. So you can
>> store required information in your internal structures and check it
>> *before* resuming, not *after* resuming.
> 
> Seems to be I got the point. Thanks for the advice.
> 
>> Resume/suspend repeated cycles without processing of information - is
>> ineffective and wastes a lot of resources.
> 
> There is a little problem. If I would proceed the data and right after
> that I suspend the connection, then I must keep this (read) data
> somewhere, because a new data already is arrived. This leads to next
> problem: more suspended connections means that the app. will keep even
> more data (one proceeded, one in MHD buffers). IMHO, 1) the
> application becomes overcomplicated; 2) there is even more wasting of
> resources.
You are storing connection handler somewhere anyway.
Declare:
struct my_conn_info
{
  const MHD_connection * conn;
  enum req_method {req_UNK, req_GET, req_POST, req_HEAD, req_OTHER} method;
  const char * url;
  unsigned int timeout;
  int other_data1;
  char other_data2;
} my_connection
and use it instead of MHD connection handler for you internal functions.
Pretty simple and take only a few more bytes per connection.
It's really much lighter comparing to calling heavy systems call like
send/recv/select.
And you can use it with callbacks as well (as con_cls). Anyway you need
to store connection specific data while you incrementally processing
incoming data.

> 
> Either, I chose the wrong tool :)

This is a free software. You always have a choice. :)


>> PS If you will check master on official git, you may find support of
>> your ineffective way of processing.
> 
> Yes, I have tested the patch. As I suggested early, it's works
> flawlessly. It is harmless, even if you say that is "wrong way" :)
> Ok, lets finish at this point, I must finish my project. Later, I will
> give you a feedback.
> 

Good to know that it's working.
Send more reports! And thanks for that report.

-- 
Best Wishes,
Evgeny Grin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]