public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Mills <johnmills@speakeasy.net>
To: Alok Singh <alok.singh@broadcom.com>
Cc: John Mills <JMills@airdefense.net>,
	   eCos Users <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Re: Network TCP Handler: stale socket disposal
Date: Tue, 25 Sep 2007 14:56:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0709250946540.12695-200000@otter.localdomain> (raw)
In-Reply-To: <E06E3B7BBC07864CADE892DAF1EB0FBD01146A8B@NT-SJCA-0752.brcm.ad.broadcom.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2467 bytes --]

All -

First, please excuse my attaching a patch here, but I would like to 
respond once (or a few times &8-) in case it's helpful.

Second, my reply to Mr. Singh failed posting because it originated from a 
reader that can't enforce text-only formatting. Sorry.

Third, I post this patch for test and discussion purposes. It seems to 
help in our limited case, but comes with no guarantee. I would appreciate 
hearing others' experience.

Thanks for your patience.

 - John Mills

On Tue, 25 Sep 2007, Alok Singh wrote:

> John,
 
> Please post it in whatever form you deem as appropriate.  Let us know
> when you will be able to post it.
 
> BTW, I'm seeing a similar issue in my application.  Sockets are
> exhausted, and web is not accessible.  Ping is going through. I've kept
> Max. number of sockets as 32 while configuring ecos. The strange thing
> is that the issue comes after a long period of inactivity, i.e., no web
> activity.   
 
> Your patch will be useful.
 
> Regards,
> Alok  

> ________________________________________
> From: John Mills [mailto:JMills@airdefense.net] 
> Sent: Tuesday, September 25, 2007 6:56 PM
> To: Alok Singh
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
 
> All -
 
> I don't believe my patch was ever accepted. The eCos sources carry a
> cautionary note that such a 'hung' socket may have been placed on the
> net stack 'accept' queue, and may be in the process of acceptance by a
> user thread which could then block.
 
> I checked Linux and FreeBSD man pages on this. In Linux the blocked task
> would receive the next such incoming client and be unblocked. This is
> perfect for my application. Neither OpenBSD nor FreeBSD man pages
> address the issue specifically.
 
> I didn't try to replicate the race condition myself.
 
> eCos now uses an older version of the BSD stack, and updating it looks
> significant - well over a month's work, maybe 3 or 4 based on the time
> the original author reported for his port.
 
> The patch solved a show-stopping problem with our application and seems
> to cause no problems, so we're using it. Two other users tried the
> approach and wrote me off-list: in one case it resolved a problem, in
> the other it made no difference (either way, as far as I know). I can
> share the patch on a "no warranty" basis, but would prefer to post it
> appropriately rather than circulating it randomly.
 
>  - John Mills

[-- Attachment #2: Patch discards stale sockets --]
[-- Type: TEXT/PLAIN, Size: 907 bytes --]

--- /opt/ecos/ecos-2.0/packages/net/bsd_tcpip/v2_0/src/sys/kern/uipc_socket.c	2003-02-12 10:29:52.000000000 -0500
+++ ./uipc_socket.c	2007-08-28 16:11:56.000000000 -0400
@@ -242,6 +246,11 @@
 			TAILQ_REMOVE(&head->so_incomp, so, so_list);
 			head->so_incqlen--;
 		} else if (so->so_state & SS_COMP) {
+			 if((so->so_error == ECONNRESET) ||
+				 (so->so_error == ECONNREFUSED)){ // forced drop if flagged
+				  TAILQ_REMOVE(&head->so_comp, so, so_list);
+				  head->so_qlen--;
+			 } else {
 			/*
 			 * We must not decommission a socket that's
 			 * on the accept(2) queue.  If we do, then
@@ -249,11 +258,13 @@
 			 * that the listening socket was ready.
 			 */
 			return;
+			 }
 		} else {
 			panic("sofree: not queued");
 		}
 		head->so_qlen--;
 		so->so_state &= ~SS_INCOMP;
+		so->so_state &= ~SS_COMP;
 		so->so_head = NULL;
 	}
 	sbrelease(&so->so_snd, so);

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

  reply	other threads:[~2007-09-25 14:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 12:20 Alok Singh
     [not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
2007-09-25 13:41   ` Alok Singh
2007-09-25 14:56     ` John Mills [this message]
2007-09-28 12:06       ` Alok Singh
2007-09-28 13:31         ` John Mills
2007-10-02  9:15           ` Lars Povlsen
2015-05-11 16:39 Weili Yao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0709250946540.12695-200000@otter.localdomain \
    --to=johnmills@speakeasy.net \
    --cc=JMills@airdefense.net \
    --cc=alok.singh@broadcom.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=john.m.mills@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).