libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] suspend/resume patch


From: Flavio Ceolin
Subject: Re: [libmicrohttpd] suspend/resume patch
Date: Wed, 20 Apr 2016 14:55:28 -0300
User-agent: Mutt/1.5.24 (2015-08-30)

Hi,

> I don't really know enough about this to offer a strong opinion.  With that
> caveat in place...
> 
> I tend to try to write code that is 'fault tolerant' when possible - if I'm
> asking the code to do something that's already done, it ends up being a
> no-op.  When writing multi-threaded code, that's usually a lot easier than
> dealing with the (possible) error.
> 
> In this case - I see Christian's point.  This could be a serious error in
> the app.  However - with what I just said above in mind - maybe MHD being
> "nicer" about it would be helpful in some situations.
> 
> As a compromise, how about some way to just ask MHD if the connection is
> already suspended?  If you have a situation like Flavio's, he'd still have
> to do the check, but at least this way he's not having to keep a parallel
> state in his code.  I.e., he could write his own 'suspend' function that
> checks if it's suspended and just makes the MHD suspend call if it's not.
> Not dissimilar to what he's doing now, but the storage is probably more
> reliable.
> 
> 
> Ken

I think this also could be added. I still think you should avoid errors
when it's possible and easy to do.

> 
> 
> On Wed, Apr 20, 2016 at 1:41 PM, Evgeny Grin <address@hidden> wrote:
> 
> >
> >
> > On 20.04.2016 19:27, Flavio Ceolin wrote:
> > > Any other thoughts about this ? Should I consider this change not wanted
> > > ?
> >
> > Please note, that connection in suspended mode still counted for IP
> > limits and pre-daemon limit, but will not timeout.
> > You changes are not perfectly thread-safe. If you don't know connection
> > suspended/resumed state, then MHD_resume_connection() could return but
> > connection will be suspended (as state may be changed by other thread
> > during execution of MHD_resume_connection() in this thread).

Yes, I saw the mistake :( Fortunately it's easy to do inside the mutex
lock/unlock. Now it's just a matter of we choose the behaviour that we
want.

> >
> >
> > --
> > Best Wishes,
> > Evgeny Grin
> >
> >

-- 
Flavio Ceolin
Intel Open source Technology Center



reply via email to

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