This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: RFC, fix for bogus timeouts in select()
- From: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: ecos-patches at sources dot redhat dot com
- Date: Tue, 02 Nov 2004 09:55:52 +0100
- Subject: Re: RFC, fix for bogus timeouts in select()
- References: <1098362231.21934.21.camel@famine> <20041022084410.GP2141@lunn.ch> <1098435729.23253.20.camel@famine> <20041022091759.GR2141@lunn.ch> <1098437664.23253.38.camel@famine> <20041022100559.GT2141@lunn.ch>
On Fri, 2004-10-22 at 12:05, Andrew Lunn wrote:
> > So what I should look for is(i.e. a bug exists if):
> >
> > 1. select() sleeps
> > 2. data arrives
> > 3. thread on which select() executes is starved until after timeout
> > expires
> > 4. select() wakes up after timeout has expired *and* data has arrived
> > 5. select() returns a timeout instead of "data arrived"
> >
> > I claim the above happens, but I have not provided evidence.
>
> If you can prove that is happening, then this is a bug.
>
> You should be able to prove this with kernel Instrumentation. See
>
> http://ecos.sourceware.org/docs-latest/user-guide/debugging-techniques.html
>
> You are interested in CYG_INSTRUMENT_CONDVAR() and
> CYG_INSTRUMENT_THREAD()
>
> You might find packages/kernel/current/host/instr usefull in helping
> decrypt the results.
I'm afraid I'll have to orphan this investigation since the workaround
is so trivial(lack of sponsoring larger issue at stake).
>
> Andrew
>
--
Øyvind Harboe
http://www.zylin.com