[ECOS] atHTTP hangs connections on select() errors

[ECOS] atHTTP hangs connections on select() errors

[Tad]

athttp often locks up resources and never frees them if select() returns
an error.

A robust implementation of athttp will want to change the main
cyg_httpd_daemon listen() loop so that
cyg_httpd_close_unused_sockets(listener); is called regardless of the
return value from the listen() call.  Otherwise, errors from listen()
will prevent all connections (possibly causing the errors) from ever
timing out and being shut down.  The system will quickly run out of
sockets, as all will be left in the ESTABLISHED state.  Not theoretical,
fairly easy to get listen() to return errors.

Also see my post about athttp hanging in accept() when out of sockets if
attempting a robust port.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] atHTTP hangs connections on select() errors

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tad wrote:
> athttp often locks up resources and never frees them if select() returns
> an error.
> 
> A robust implementation of athttp will want to change the main
> cyg_httpd_daemon listen() loop so that
> cyg_httpd_close_unused_sockets(listener); is called regardless of the
> return value from the listen() call.  Otherwise, errors from listen()
> will prevent all connections (possibly causing the errors) from ever
> timing out and being shut down.  The system will quickly run out of
> sockets, as all will be left in the ESTABLISHED state.  Not theoretical,
> fairly easy to get listen() to return errors.
> 
> Also see my post about athttp hanging in accept() when out of sockets if
> attempting a robust port.

This is a community project - you'll only get out of it what you
want to put [back] into it.  So, instead of sending multiple nagging
emails [about the same thing], why not propose some patches?  You've
obviously looked at the code, docs, etc - it seems only fair that
you help out.

Persistent complaining without pitching in will probably just
turn folks ears deaf...

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGbckwmaKbSsQGV8ARAkTrAJ9NyDK3n9NPO4wZ1aZOSmu8xOBhLgCeOJ5P
jl4IA2wXef3G9+QDX8Ie/QM=
=CVmW
-----END PGP SIGNATURE-----

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] atHTTP hangs connections on select() errors

[Andrew Lunn]

On Mon, Jun 11, 2007 at 02:48:06PM -0800, Tad Artis wrote:
> athttp often locks up resources and never frees them if select() returns 
> an error.
> 
> A robust implementation of athttp will want to change the main 
> cyg_httpd_daemon listen() loop so that 
> cyg_httpd_close_unused_sockets(listener); is called regardless of the 
> return value from the listen() call.  Otherwise, errors from listen() 
> will prevent all connections (possibly causing the errors) from ever 
> timing out and being shut down.  The system will quickly run out of 
> sockets, as all will be left in the ESTABLISHED state.  Not theoretical, 
> fairly easy to get listen() to return errors.

Could you provide a patch for this?

      Thanks
        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] atHTTP hangs connections on select() errors

[Tad Artis]

athttp often locks up resources and never frees them if select() returns 
an error.

A robust implementation of athttp will want to change the main 
cyg_httpd_daemon listen() loop so that 
cyg_httpd_close_unused_sockets(listener); is called regardless of the 
return value from the listen() call.  Otherwise, errors from listen() 
will prevent all connections (possibly causing the errors) from ever 
timing out and being shut down.  The system will quickly run out of 
sockets, as all will be left in the ESTABLISHED state.  Not theoretical, 
fairly easy to get listen() to return errors.

Also see my post about athttp hanging in accept() when out of sockets if 
attempting a robust port.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss