RE: [ECOS] Re: What causes interrupted network system calls?

["Carruth, Rusty" <Rusty dot Carruth at smartm dot com>]

> .....
> 
> >  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
> >
> 
> Very weird. The current FreeBSD documentation also does not mention
> EINTR. However Linux man pages do, as does the POSIX standard.
> 
> 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.
> 

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.  

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