Grant Edwards <[email protected]> writes: > On 2009-10-28, Nick Garnett <[email protected]> wrote: > > Grant Edwards <[email protected]> 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 into errno. 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
