From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5921 invoked by alias); 28 Oct 2009 18:15:54 -0000 Received: (qmail 5912 invoked by uid 22791); 28 Oct 2009 18:15:53 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtrly02.smartm.com (HELO smtrly02.smartm.com) (65.249.22.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Oct 2009 18:15:48 +0000 Received: from sr-fre-exch01.smartm.internal ([10.0.10.35]) by smtrly02.smartm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 11:13:43 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 18:15:00 -0000 Message-ID: <9EFFCEC257D2B649BCD6495F5C704AA9090C48CE@sr-fre-exch01.smartm.internal> In-Reply-To: References: <9EFFCEC257D2B649BCD6495F5C704AA9090C479E@sr-fre-exch01.smartm.internal> From: "Carruth, Rusty" To: "Grant Edwards" Cc: Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Re: What causes interrupted network system calls? X-SW-Source: 2009-10/txt/msg00176.txt.bz2 > ..... >=20 > > 2) EINTR isn't listed as one of the possible return values for > > send(), but we seem to be getting it: > > http://ecos.sourceware.org/docs-3.0/ref/net-common-tcpip-manpages- > send.html > > >=20 > Very weird. The current FreeBSD documentation also does not mention > EINTR. However Linux man pages do, as does the POSIX standard. >=20 > In general net stack calls return EINTR only if the thread is broken > out of a wait by cyg_thread_release(), and only POSIX signal handling > generally does that. If the application is using signals, then maybe > the signal masks need to be set up differently. >=20 Yes, now I remember - signals. Yes, signals (and threads) are the most likely culprit(s) (again, using Solaris and Linux as my base of reference). Signals, by the way, are used by asynch I/O (at least for Solaris and Linux), and probably other non-obvious things. So just because your application doesn't explicitly use signals doesn't mean it isn't using them. Also, using threads GREATLY increases your chance of EINTR. (Again, Solaris and Linux) I just saw Grant's other email, where he says that they don't think they are using signals. However, I've seen cases where signals get used by the underlying code even though you don't ask for it.=20=20 Does your software (explicitly) use threads? Grant also said: > I've just been told that retrying doesn't seem to help. Once you get an -> EINTR, it will happen 5-10 times in a row. That's interesting. I was going to ask if you could get some sort of snapshot of what was happening, and came up with a silly idea: When you get the first EINTR, immediately set up a signal handler to capture all signals, and see what signal is causing the interrupted system call. (I assume eCOS can do that - sorry I'm debugging from a different frame of reference and with no eCOS experience - but I do remember having 'much fun' with EINTR, and hope I can help even without the eCOS knowledge). Anyway, finding out what signal(s) is (are) causing the interrupt(s) may give a hint as to where it's (they're) coming from. Rusty -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss