libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] feature request: get connection_timeout value from M


From: Evgeny Grin
Subject: Re: [libmicrohttpd] feature request: get connection_timeout value from MHD_Connection structure
Date: Tue, 14 Mar 2017 23:30:23 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 14.03.2017 21:18, Vitaliy T wrote:
> I want a function to retrieve the previous value of the element
> connection_timeout
> from MHD_Connection structure. In such way I may store this value somewhere
> and restore it back after calling MHD_resume_connection().

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.

> Yes, I understand that I can use the global connection timeout from
> MHD_OPTION_CONNECTION_TIMEOUT to restore back a timeout per connection.
> But it does not cover all cases.
> 
> I would say even more. Because MHD_Connection is opaque it is not very useful
> to pass everywhere MHD_Connection & MHD_Daemon. So, the implementation
> might be something like this:
> 
> const union MHD_ConnectionInfo *
> MHD_get_connection_info (struct MHD_Connection *connection,
>   enum MHD_ConnectionInfoType info_type,
>   ...)
> {
>    struct MHD_Daemon *daemon = connection->daemon;
> 
>    /* somehow we must to get an actual timeout, I did not read all
> sources  yet */
>    /* no critic about missing type cast */
>    if (connection->connection_timeout == -1)
>       return daemon->connection_timeout;
>    else
>       return connection->connection_timeout;
> }

By making any internal structures transparent to external code we
prevent any modification of structures without breaking ABI.
By keeping internal structures opaque we avoiding keep of unused old
parts of such structures. Code is much easy to maintain and we provide
almost 100% backward compatibility on both API and ABI levels.
That's the reason why we use specialized structures for API.


-- 
Wishes,
Evgeny



reply via email to

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