This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_kill and signal lost or pending?


"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 **


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]