Re: [ECOS] pthread_kill and signal lost or pending?

["Zhichao Hong" <zhichao.hong@gmail.com>]

Nick,

Thank you for you quick response!  Is the sigaction and sigqueue in
eCos process wise or thread wise?  If sigqueue is called, is it for
the whole process which is always 0 in eCos get the signal?

Zhichao

On Mon, Apr 7, 2008 at 10:25 AM, Nick Garnett <nickg@ecoscentric.com> wrote:
>
> "Zhichao Hong" <zhichao.hong@gmail.com> writes:
>
>  > I am having some confusion about how signals are handled in the POSIX
>  > layer.  Basically, I am not sure whether signals can get lost or not
>  > in the eCos implementation.  I created a producer and consumer
>  > threads.  In the producer, I will increment a counter every time when
>  > pthread_kill is called.  And in the consumer which is blocked on
>  > pselect with no signal blocking (zero signal masked), it also
>  > increment a counter whenever it receives a signal.  I found, the
>  > producer called pthread_kill 20 times whereas the consumer only got it
>  > once or twice.  This leads me to think the signals are either pending
>  > forever or lost.  However, when I introduce a mailbox between the
>  > producer and consumer.  Every time when the producer put the message
>  > in the mailbox and then signals the consumer.  On the other side,
>  > consumer get a message and wait for the next signals.  There are still
>  > less signals received than the ones sent (200 sent vs 5 received).
>  > But it seems that the consumer does manage to consume all the messages
>  > the producer sent even with many lost signals.  Can anyone help
>  > explain why this odd behavior occurs?  This is a ARM7TDMI micro.
>
>
>  There is no 1-1 correspondence between calls to pthread_kill() and
>  signal delivery. pthread_kill just sets a bit in the destination
>  thread's pending signal mask. Many calls can be made before the
>  handler is called. Individual signals can only be separated if you use
>  sigqueue() and sigaction(). Even then the number of queued signals is
>  limited to a small number. This is a property of the POSIX standard
>  and is true in eCos as well as Linux and BSD.
>
>  While signals were a reasonable mechanism for delivering simple
>  asyncronous events to processes in the original UNIX design, they are
>  poorly suited to multithreaded or real time systems. Efforts to fix
>  this up in BSD, SysV and POSIX have not been successful. Signal
>  support in eCos is really only present to help porting existing
>  code. Signals should never be used for new code. Avoid them!
>
>  --
>  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.
>  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
>  **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
>
>



-- 
Zhichao Hong, CSDP
zhichao.hong@computer.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss