[ECOS] Re: What causes interrupted network system calls?
Wed Oct 28 18:27:00 GMT 2009
Grant Edwards <firstname.lastname@example.org> writes:
> On 2009-10-28, Nick Garnett <email@example.com> wrote:
> > Grant Edwards <firstname.lastname@example.org> writes:
> >> 1) in the same situation we never saw EINTR with the previous
> >> network stack.
> > It is probable that the OpenBSD stack totally ignored signals
> > and therefore wouldn't necessarily do the right thing. The
> > FreeBSD stack is better integrated with POSIX support.
> We're not using POSIX support.
In which case there is something else going on. The only place that
the FreeBSD stack generates an EINTR result is in cyg_tsleep() when
the call to cyg_semaphore_timed_wait() returns false, and it is not a
timeout. Something must either be zapping that semaphore in some way,
or the thread is being released by something else. The OpenBSD stack
has similar code, so it is not immediately clear why one stack is
doing this and the other not.
Are you sure that the EINTR result is coming from the stack itself and
is not simply a leftover in errno from a previous call? Try zeroing
errno before the call.
Also, in the original message you mentioned -EINTR. While negative
error codes are returned from some drivers, network drivers don't do
this. Negative driver error codes are also negated before being put
So, I don't know where -EINTR is coming from, but it should never find
its way into errno. I think your best approach is to track down where
this error code is actually coming from.
Nick Garnett eCos Kernel Architect
eCosCentric Limited http://www.eCosCentric.com The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No: 4422071
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss